OSDev

Фраза насчет DMA была сильно неоднозначной, поэтому автор сам виноват, что его неправильно поняли. Для работы с ж/дисками мне не требуются смежные физ. страницы, но, да, естественно я использую DMA.

Обоснуйте. У меня code, data, bss ядра вместе взятые обычно занимаю меньше 4 мег. Можно конечно данные секции для всех модулей размещать отдельно от секций для резерва пространства, но так обычно не делают, т.е. все секции одного модуля идут последовательно. Единственное, для чего подходят большие страницы, так это MMIO-доступ к большим аппаратным буферам типа видеобуфера.

Потом впилить - может оказаться серьёзной головной болью. Например, поиск смежных страниц практически несовместим с выделением страниц при помощи стека. Придётся или менять алгоритм, или изначально, до включения алгоритма и наполнения стека, выделять отдельный буфер для таких операций с риском недо- или переполнения этого буфера. Поэтому в любом случае имеет смысл задуматься об этом на этапе проектирования аллокатора страниц.


С цитированим при помощи тэгов движка существенно проще воспринимать структуру - кто что писал. Заметь, я перецитировал текст Станислава вверху каноническим образом, чтобы было понятно, кто о чём .

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

По-моему, вполне нормально иметь функцию выделения памяти, у которой (функции) есть параметр, указывающий особенности выделения памяти. Соотв. потом можно туда впилить опцию для выделения непрерывного буфера. Про алгоритмы соглашусь, но имхо их лучше брать готовыми и с таким API, что поменять один на другой можно легко. Примерно как библиотечный qsort - прототип один, а внутри [strike]может быть хз что[/strike]можно ставить разное и смотреть чего получается.

А это всё от [strike]безблагодатности[/strike] незнания о древовидных движках. Хотя бы том же wwwconf, хотя это и не лучший вариант.
Да, кому-то тяжело их воспринимать потому что.. ладно, по разным причинам. Но офигенную плотность и удобство восприятия большого количества информации это не отменяет. Единственный минус - в одном сообщении нескольким пользователям не очень удобно отвечать, но там это и не нужно.

А у меня софт приходится крутить на машинах с 12 процессорами и 24Гб оперативы (а то и 16/64). Вычислительные задачи (да и прочий современный софт) всякие жрут много и смело. На каждый процессор своя таблица страниц, а ещё и нередко EPT, представили сколько всё это весит? Можно хитро merge'ить таблицы, но всё равно они немало занимают. Но они - полбеды. Беда в том что кеши и, особенно, TLB - не резиновые. И раздувать кеши нельзя, время поиска растёт пропорционально логарифму размера, так что увеличение L1 с 16кб до 32 в своё время дало нехилый прирост (ценой выборки из кеша не за 2, а за 4 такта, насколько помню), а вот дальше L1 у процессоров не особо рос, как можно заметить. Наращивать уровни прозрачного кеша - фууу, чтобы понять почему - рекомендую поботать модель памяти в CUDA, там поначалу можно мозг сломать, а потом вот проникаешься, что не просто так объясняют что GDDR5 - внезапно, медленная память.

Да, жить в 2012 сложно, но даже на нищеброд-железе стремление к отсутствию фрагментации памяти и выделению памяти большими из последовательных страниц даёт плюшки: часто вспоминаю статью из журнала "Программист" за сентябрь 2001го года про оптимизацию обращений к памяти с учётом того что память состоит из банков и требует постоянных операций обновления (refresh). Причём, никаких особо грязных трюков, чистая сишечка. Да, > 2001 > 2012 , но нынче разрыв производительности между процессором и динамической памятью только усугубился.

Это миф. Тоже так думал, пока не начал тестировать. Оказывается скорость памяти в среднем тоже возрасла прилично.

Естественно возросла, но разрыв увеличился. Или вы думаете что в десктопах почти нет процов на 5ГГц (а в кластерах используются ~2ГГц) только из-за проблем с теплоотведением и прочих технических? Нет, частоты не повышают в т.ч. потому что это, внезапно, ещё и прибавки производительности в задачах, активно юзающих память и/или коммуникации, не даёт.

Also, смотрю с укором на тех кто пишет "пока не начал тестировать", а числовые данные не приводит.
Могу порекомендовать RandomAccess из пакета HPCC.

P.S> у меня есть опасение: тема стала уходить в оффтоп.

Вот смотри частота процессора увеличилась в 4 раза. Эффективная частота ещё в 3 раза. Число ядер в 4 раза.
4*3*4=48
Память частота увечилась 10 раз(по задержкам только в 3 раза) эффективная в 4 раза. Число каналов стало 3.
Задержки не сильно заметны в виду того что их эффективно обходят.
3*4*3=36
10*4*3=120

Пожалуйста, ну не надо мне рассказывать про пиковую производительность, она не интересна, рассказывайте про реальную.

Ну снова несодержательные маркетолохические лозунги, снова самообман. Только производительность на типовых задачах[strike], только хардкор[/strike].

А написать реальный тест памяти -- очень и очень непросто. Хотя бы из-за того, что такой тест просто обязан обойти эффекты, вызываемые работой кэша, иначе он будет показывать производительность именно кэша, а не ОЗУ.

Ну это как раз довольно просто. Когда мы с приятелем баловались публикациями в Компьютер Пресс, он написал (на асме) программу тестирования производительности разных уровней кэша и памяти. Чтобы протестировать память, нужно читать/писать объёмы данных, не помещающиеся в кэш.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Такой тест будет некорректным. Чтобы обмануть кэш, недостаточно просто грузить большие объёмы. Надо учитывать, в частности, сколько реально считывается в кэш при каждом промахе (полная строка кэша, а отнюдь не те несколько байтов, которые затребованы инструкцией); кроме того, интерес пропускает не только пиковая пропускная способность памяти, но ещё и латентность -- на разных алгоритмах на итоговую производительность может влиять сильней либо то, либо другое. С записью надо гарантировать, что данные реально записаны в память, а не валяются себе в кэше. Ну и т.д. В общем, не такая элементарная это задача.