Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
| | | |
Это было когда-то под ДОСом и первыми версиями Виндовса. 24.02.04 16:33 Число просмотров: 1035
Автор: tdes@work Статус: Незарегистрированный пользователь
|
Все логично. 10х
Значит объем данных, которые можно внести в оперативку одним процессом ограничен только размером оной и архитектурой компа (16, 32, 64 бит).
Ну и тогда хотел спросить, где есть РТФМ по ручной сборке ядра линуксовского ?
|
|
<beginners>
|
Возник ряд вопросов 24.02.04 15:31
Автор: tdes@work Статус: Незарегистрированный пользователь
|
1. Предположим я хочу загрузить в оп.память гигабайтный массив, как это можно сделать ?
2. Реально ли (например на базе ядра линукс), написать систему, которая будет поддерживать минимально необходимый хард( клавиатура, монитор, сетевой интерфейс, память, райд-массив), при этом соответственно используя минимальные ресурсы CPU ?
Все это для максимальной эффективности работы с информацией в оперативке (то есть, по сути нужен очень урезанный вариант OS).
очень приветствуются соответствующие ссылки
10x
|
|
А памяти - гигабайт? Что значит "загрузить"? На каком... 24.02.04 15:39
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> 1. Предположим я хочу загрузить в оп.память гигабайтный
> массив, как это можно сделать ?
А памяти - гигабайт? Что значит "загрузить"? На каком алгоритмическом языке?
На "С" это может быть так:
char *ptr = (char *)malloc( 1000000000 );
read( fd, ptr, 1000000000 );
> 2. Реально ли (например на базе ядра линукс), написать
> систему, которая будет поддерживать минимально необходимый
> хард( клавиатура, монитор, сетевой интерфейс, память,
При сборке ядра и так можно указать, чтоб оно ничего лишнего не поддерживало. Может все и на одну дискетку влезть.
> райд-массив), при этом соответственно используя минимальные
> ресурсы CPU ?
Ядро и вся ОС и так использует ресурсы по минимуму.
> Все это для максимальной эффективности работы с информацией
> в оперативке (то есть, по сути нужен очень урезанный
> вариант OS).
>
> очень приветствуются соответствующие ссылки
> 10x
|
| |
я просто как неспециалист слышал что-то, что когда массив... 24.02.04 15:52
Автор: tdes@work Статус: Незарегистрированный пользователь
|
> А памяти - гигабайт? Что значит "загрузить"? На каком
> алгоритмическом языке?
> На "С" это может быть так:
> char *ptr = (char *)malloc( 1000000000 );
> read( fd, ptr, 1000000000 );
я просто как неспециалист слышал что-то, что когда массив больше одного сегмента, нужно как-то по хитрому извращаться
> Ядро и вся ОС и так использует ресурсы по минимуму.
К, так вот как узнаьть всё-таки, каков именно процент использования CPU операционкой
|
| | |
Это было когда-то под ДОСом и первыми версиями Виндовса.
24.02.04 16:18
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> я просто как неспециалист слышал что-то, что когда массив
> больше одного сегмента, нужно как-то по хитрому извращаться
Это было когда-то под ДОСом и первыми версиями Виндовса.
> К, так вот как узнаьть всё-таки, каков именно процент
> использования CPU операционкой
При участии в проекте dnet, процессор загружен процентов на 100, причем самой програмкой подбора пароля. Операционка в это время не работает.
Если же написать програмку, которая в цикле запрашивает "который час", то при загрузке ЦПУ 100 процентов как раз именно столько будет приходится на операционку.
При копировании файлов около 1% жрет сама программа, до 10% может жрать операционка, остальное время процессор "простаивает", ожидая окончание дисковых операций.
Операционка "жрёт" процессорное время, только когда произойдет аппаратное прерывание или прикладная программа выполнит программное прерывание. После выполнение нескольких (десятков) микрокоманд либо управление обратно передается программе, либо она ждет окончания операций внешними устройствами. Что ей надо операционке-то два на два помножить и всего-то, чтоб вычислить откуда файл с диска считывать или в кеши его найти, RC5 ей ломать вовсе не надо. Короче ничего она "жрать" не должна.
|
| | | |
Это было когда-то под ДОСом и первыми версиями Виндовса. 24.02.04 16:33
Автор: tdes@work Статус: Незарегистрированный пользователь
|
Все логично. 10х
Значит объем данных, которые можно внести в оперативку одним процессом ограничен только размером оной и архитектурой компа (16, 32, 64 бит).
Ну и тогда хотел спросить, где есть РТФМ по ручной сборке ядра линуксовского ?
|
| | | | |
На самом деле даже больше, чем оперативки. Под линуксом... 24.02.04 16:48
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Все логично. 10х
> Значит объем данных, которые можно внести в оперативку
> одним процессом ограничен только размером оной и
> архитектурой компа (16, 32, 64 бит).
На самом деле даже больше, чем оперативки. Под линуксом половина массива может сидеть в ОЗУ, половина может быть в свопе, а половина вообще нигде (прикольно).
> Ну и тогда хотел спросить, где есть РТФМ по ручной сборке
> ядра линуксовского ?
Если набрать # make menuconfig, то хелп к каждому пункту можно будет прям в меню конфигурации, и удобнее, а то нечаянно ошибешся, вместо "Y" "N" нажмешь и все заново. Есть еще # make xmenuconfig, для конфигурирования мышкой под графическим интерфейсом. Хелпов - море.
|
| | | | | |
а половина вообще нигде (прикольно) - это я надеюсь шутка юмора ? ;) 24.02.04 16:54
Автор: tdes@work Статус: Незарегистрированный пользователь
|
|
|
| | | | | | |
В том то и дело, что серьёзно. Несколько лет назад... 24.02.04 17:32
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
В том то и дело, что серьёзно. Несколько лет назад эксперименты ставил (с коллегой) - сначала написали програмку, которая маллочит на корелефт, потом ждет (герчар), что посмотреть - что с памятью происходит с другого терминала. Так вот свободной памяти почему-то не уменьшилось. Запустили несколько копий этой программы и убедились, что они в совокупности отмаллочили памяти во много раз больше, чем все ОЗУ вместе со свопом. Потом програмку подправили, и перед ожиданием впихнули цикл заполнения этой отмаллоченой памяти. Память откусывалась по 4кб, потом своп начал кончаться, потом мы эту програмку "прибить" не смогли.
То есть каждая програмка может отмаллочить памяти на свободную+свободный_своп, а вот когда они ее заполнять начнут, она (свободная) "таять" будет...
|
| | | | | | | |
Прикольно 25.02.04 01:50
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 25.02.04 01:53 Количество правок: 1
|
> То есть каждая програмка может отмаллочить памяти на
> свободную+свободный_своп, а вот когда они ее заполнять
> начнут, она (свободная) "таять" будет...
Т.е. при выделении памяти просто в контексте процесса помечяаются диапазоны виртуальный адресов как выделенные а их мэппинг на физические или в своп происходит во время первого обращения к ним. Оно так конечно быстрее только правильнее ли так будет - вопрос. Я ведь могу написать в своей программе обработку ситуации когда недостаточно памяти, при ее выделении, а так программа просто об этом не узнает. Так что это большой вопрос - фича это или баг. Имхо так как винды при этом поступают все же корректнее. Хотя с юзанием API VirtualAlloc можно сделать такой же фокус как в линухе выделив много памяти а потом по мере требования делать ей COMMIT но имхо такое поведение стандартной malloc не есть рулез.
|
| | | | | | | | |
Вполне нормальное поведение 25.02.04 14:24
Автор: amirul <Serge> Статус: The Elderman
|
> юзанием API VirtualAlloc можно сделать такой же фокус как в
> линухе выделив много памяти а потом по мере требования
> делать ей COMMIT но имхо такое поведение стандартной malloc
> не есть рулез.
Ленивое управление ресурсами называется. То бишь откладывать работу до тех пор, пока ее уже невозможно не сделать.
Если тебе действительно важно, выставляй MEM_COMMIT в VirtualAlloc-е. Тогда страницы точно упадут или в своп или в физическую память. Думаю в юнихе тоже можно управлять поведением мемори манагера
|
| | | | | | | | |
Очень похоже на то.
25.02.04 11:16
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Т.е. при выделении памяти просто в контексте процесса
> помечяаются диапазоны виртуальный адресов как выделенные а
> их мэппинг на физические или в своп происходит во время
> первого обращения к ним. Оно так конечно быстрее только
Очень похоже на то.
> правильнее ли так будет - вопрос. Я ведь могу написать в
На вкус и цвет - товарищей нет, у каждого свой вкус, абсолютной истины не существует.
> своей программе обработку ситуации когда недостаточно
> памяти, при ее выделении, а так программа просто об этом не
Обрабатывайте, когда потребуется памяти больше, чем ОЗУ+СВОП.
> узнает. Так что это большой вопрос - фича это или баг. Имхо
> так как винды при этом поступают все же корректнее. Хотя с
> юзанием API VirtualAlloc можно сделать такой же фокус как в
> линухе выделив много памяти а потом по мере требования
> делать ей COMMIT но имхо такое поведение стандартной malloc
> не есть рулез.
Слышал, что в Юниксах не менее интересные фичи есть - можно память в файл отобразить, и, что самое прикольное, файл отобразить в память.
И вообще, у кого Юниксы под рукой - напишите что они с памятью вытворять умеют.
|
| | | | | | | | | |
Винды тоже умеют мэпить файлы в память 25.02.04 14:19
Автор: amirul <Serge> Статус: The Elderman
|
> Слышал, что в Юниксах не менее интересные фичи есть - можно
> память в файл отобразить, и, что самое прикольное, файл
> отобразить в память.
CreateFileForMapping/MapViewOfFile/UnmapViewOfFile
Причем именно это и используется для отображения например модулей (exe-ники, dll-ки всякие).
> И вообще, у кого Юниксы под рукой - напишите что они с
> памятью вытворять умеют.
Да в общем то тоже что и винды.
|
| | | | | | | | | | |
Они не просто это «умеют», они это делают практически везде ;-) 26.02.04 06:40
Автор: HandleX <Александр М.> Статус: The Elderman
|
> > И вообще, у кого Юниксы под рукой - напишите что они с
> > памятью вытворять умеют.
> Да в общем то тоже что и винды.
Вся виртуальная память в виндах — это сплошные Mappings. Не в своп, так в exe\dll. Устройства хранения — вот, CD-ROM не читается, а винда пишет в логи: «Ошибка страничного обмена»! Игры с отображением страниц памяти процесса в ядро и обратно — называется "Fast I/O". И под всем этом генерализованный кэш… В общем, получается нехило.
Key Features of the Windows 2000 Cache Manager
The Windows 2000 cache manager has several key features:
Supports all file system types (both local and network), thus removing the need for each file system to implement its own cache management code
Uses the memory manager to control what parts of what files are in physical memory (trading off demands for physical memory between user processes and the operating system)
Caches data on a virtual block basis (offsets within a file)—in contrast to most caching systems, which cache on a logical block basis (offsets within a disk partition)—allowing for intelligent read-ahead and high-speed access to the cache without involving file system drivers (This method of caching, called fast I/O, is described later in this chapter.)
Supports "hints" passed by applications at file open time (such as random versus sequential access, temporary file creation, and so on)
Supports recoverable file systems (for example, those that use transaction logging) to recover data after a system failure
Although we'll talk more throughout this chapter about how these features are used in the cache manager, in this section we'll introduce you to the concepts behind these features.
Single, Centralized System Cache
Some operating systems rely on each individual file system to cache data, a practice that results either in duplicated caching and memory management code in the operating system or in limitations on the kinds of data that can be cached. In contrast, Windows 2000 offers a centralized caching facility that caches all externally stored data, whether on local hard disks, floppy disks, network file servers, or CD-ROMs. Any data can be cached, whether it's user data streams (the contents of a file and the ongoing read and write activity to that file) or file system metadata (such as directory and file headers). As you'll discover in this chapter, the method Windows 2000 uses to access the cache depends on the type of data being cached.
The Memory Manager
One unusual aspect of the Windows 2000 cache manager is that it never knows how much cached data is actually in physical memory. This statement might sound strange, since the purpose of a cache is to keep a subset of frequently accessed data in physical memory as a way to improve I/O performance. The reason the Windows 2000 cache manager doesn't know how much data is in physical memory is that it accesses data by mapping views of files into system virtual address spaces, using standard section objects (file mapping objects in Win32 terminology). (Section objects are the basic primitive of the memory manager and are explained in detail in Chapter 7.) As addresses in these mapped views are accessed, the memory manager pages in blocks that aren't in physical memory. And when memory demands dictate, the memory manager pages data out of the cache and back to the files that are open in (mapped into) the cache.
By caching on the basis of a virtual address space using mapped files, the cache manager avoids generating read or write I/O request packets (IRPs) to access the data for files it's caching. Instead, it simply copies data to or from the virtual addresses where the portion of the cached file is mapped and relies on the memory manager to fault in (or out) the data into (or out of) memory as needed. This process allows the memory manager to make global trade-offs on how much memory to give to the system cache versus to the user processes. (The cache manager also initiates I/O, such as lazy writing, which is described later in this chapter; however, it calls the memory manager to write the pages.) Also, as you'll learn in the next section, this design makes it possible for processes that open cached files to see the same data as do those processes mapping the same files into their user address spaces.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
