ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     07 Dec 2003  14:30:03
 To : Kirill Frolov
 Subject : Re: дефрагментация ex3 -- номер #2
 -------------------------------------------------------------------------------- 
 

 
 >>> Kirill Frolov wrote:
 
  VN>> Собственно фрагментацию-то ты не показал. А съесть какое-то количество
  VN>> памяти мелкими кусками - нормальная рабочая ситуация.
 
 KF>     Фрагмент -- это ли не мелкий кусок?
 
 Твою терминологию надо отбрасывать и пытаться использовать какую-то
 более-менее нормальную и принятую.
 У Кнута, например, говорится о "дроблении" памяти. А "фрагментация"
 слишком напоминает файловые системы, при этом подразумевая совершенно
 другое понятие.
 
  VN>> Показывало бы, например, вот такое:
  VN>> здесь выделяем память кусками по байту. Hадо перед запуском установить
 KF>    По байту ты выжрешь память на управляющие структуры malloc().
 
 Почему так сразу на управляющие структуры?
 glibc'шный аллокатор, если мне не соврали (лезть сейчас самому в него
 диалап не позволит), однобайтовые выделения оптимизирует через битовую
 таблицу.
 
 KF> Так не честно. А вот смотри, что:
 
 Сведём к сути выполняемого в программе (без проверок и с упрощением
 выражений, и в варианте без rand()):
 
 piece = 1;
 do {
   size = piece;
   x = malloc( size );
   y = malloc( size );
   total += size;
   alloc += size;
   total += size;
   piece += incr;
   free(x);
 } while( что-то выделялось && total <= limit );
 
 Ладно, total - сколько всего выделялось, alloc - сколько в сумме
 выделили... И ты удивляешься, что оно так себя ведёт?
 Оно и должно себя так вести, при таком шаблоне выделения: ты каждый
 раз просишь кусок больше, чем влезает в существующие дыры.
 Естественно, будет занята почти ровно половина.
 
 KF>    Ставить ulimit -v 65536 и запускать ./aout 2000000000 100.
 KF> Примерно, где-то 32Мб выделяется, а половина теряется неизвестно куда.
 
 Вполне известно куда: остаётся после освобождённых тобой областей такими
 кусками, которые недостаточны для выделения любого из следующих запрошенных.
 
 KF> Вот тебе и фрагментация. И что интересно: это работает в linux
 KF> (libc 2.2.5), и в pacific-c досовом (там malloc как раз на уровне
 KF> 80-х годов прошлого века). А в Watcom-C 11-й версии не работает,
 KF> в смысле ничего не фрагментируется.
 
 Hа DOS? Если да, то у него как раз аллокатор неправильный;))
 Я серьёзно: это будет значить, что он не пытается минимизировать объём
 выделенной памяти, оставив другим больше, а захватывает всю доступную
 часть conventional memory. Или это под экстендером? Тогда он захватывает
 всю дополнительную память.
 Hи один нормальный аллокатор в обстановке, где доступная от внешнего
 источника (ОС) память может расширяться, но должна экономно использоваться,
 не будет нормально работать с таким шаблоном выделения памяти.
 
 KF> И с rand() нигде не фрагментируется
 KF> толком тоже,
 
 Вот именно, и это должно было тебе показать, в чём проблема твоего метода.
 С rand() ты очень быстро будешь получать запросы достаточно мелкие,
 чтобы разместиться в существующих дырах. А с постоянным нарастанием - нет.
 
  VN>> По тому, что я слышал про glibc malloc, он такое отрабатывает хорошо.
 KF>    Оказывается, плохо. Только не надо говорить, что дескать в реальных
 KF> задачах не встречается...  Меряться фрагментацией -- тоже реальная
 KF> задача.
 
 В таком виде как у тебя - скорее нереальная. А если она где-то реальная -
 там нужно использовать другие методы распределения памяти уже на уровне
 приложения.
 
  VN>> страницу на такой блок с неиспользованием хвоста страницы, и эффективность
  VN>> использования будет около 50%.
 KF>    Во-во. Куча фрегментов, около 50%, и никак они не объединяются в один
 KF> бОльший. Разумеется, при условии, что их размер меньше 4096 байт.
 -netch-
 --- ifmail v.2.15dev5.1
  * Origin: Dark side of coredump (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор