Yoda писал(а):
Потом впилить - может оказаться серьёзной головной болью. Например, поиск смежных страниц практически несовместим с выделением страниц при помощи стека. Придётся или менять алгоритм, или изначально, до включения алгоритма и наполнения стека, выделять отдельный буфер для таких операций с риском недо- или переполнения этого буфера. Поэтому в любом случае имеет смысл задуматься об этом на этапе проектирования аллокатора страниц.
По-моему, вполне нормально иметь функцию выделения памяти, у которой (функции) есть параметр, указывающий особенности выделения памяти. Соотв. потом можно туда впилить опцию для выделения непрерывного буфера. Про алгоритмы соглашусь, но имхо их лучше брать готовыми и с таким API, что поменять один на другой можно легко. Примерно как библиотечный qsort - прототип один, а внутри [strike]может быть хз что[/strike]можно ставить разное и смотреть чего получается.
Yoda писал(а):
С цитированим при помощи тэгов движка существенно проще воспринимать структуру - кто что писал.
А это всё от [strike]безблагодатности[/strike] незнания о древовидных движках. Хотя бы том же wwwconf, хотя это и не лучший вариант.
Да, кому-то тяжело их воспринимать потому что.. ладно, по разным причинам. Но офигенную плотность и удобство восприятия большого количества информации это не отменяет. Единственный минус - в одном сообщении нескольким пользователям не очень удобно отвечать, но там это и не нужно.
phantom-84 писал(а):
Обоснуйте. У меня code, data, bss ядра вместе взятые обычно занимаю меньше 4 мег.
А у меня софт приходится крутить на машинах с 12 процессорами и 24Гб оперативы (а то и 16/64). Вычислительные задачи (да и прочий современный софт) всякие жрут много и смело. На каждый процессор своя таблица страниц, а ещё и нередко EPT, представили сколько всё это весит? Можно хитро merge'ить таблицы, но всё равно они немало занимают. Но они - полбеды. Беда в том что кеши и, особенно, TLB - не резиновые. И раздувать кеши нельзя, время поиска растёт пропорционально логарифму размера, так что увеличение L1 с 16кб до 32 в своё время дало нехилый прирост (ценой выборки из кеша не за 2, а за 4 такта, насколько помню), а вот дальше L1 у процессоров не особо рос, как можно заметить. Наращивать уровни прозрачного кеша - фууу, чтобы понять почему - рекомендую поботать модель памяти в CUDA, там поначалу можно мозг сломать, а потом вот проникаешься, что не просто так объясняют что GDDR5 - внезапно, медленная память.
Да, жить в 2012 сложно, но даже на нищеброд-железе стремление к отсутствию фрагментации памяти и выделению памяти большими из последовательных страниц даёт плюшки: часто вспоминаю статью из журнала "Программист" за сентябрь 2001го года про оптимизацию обращений к памяти с учётом того что память состоит из банков и требует постоянных операций обновления (refresh). Причём, никаких особо грязных трюков, чистая сишечка. Да, > 2001 > 2012 , но нынче разрыв производительности между процессором и динамической памятью только усугубился.