ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Kirill Frolov                        2:5030/827.2   08 Dec 2003  02:44:23
 To : Valentin Nechayev
 Subject : Re: дефрагментация ex3 -- номер #2
 -------------------------------------------------------------------------------- 
 

 
 On Sun, 07 Dec 03 13:30:03 +0300, Valentin Nechayev wrote:
  KF>>     Фрагмент -- это ли не мелкий кусок?
  VN> Твою терминологию надо отбрасывать и пытаться использовать какую-то
  VN> более-менее нормальную и принятую.
  VN> У Кнута, например, говорится о "дроблении" памяти. А "фрагментация"
 
    Ладно, пусть будет дробление, чтобы не вводить в заблуждение никого.
 
  KF>> Так не честно. А вот смотри, что:
  VN> Сведём к сути выполняемого в программе (без проверок и с упрощением
  VN> выражений, и в варианте без rand()):
  VN> piece = 1;
  VN> do {
  VN>   size = piece;
  VN>   x = malloc( size );
  VN>   y = malloc( size );
  VN>   total += size;
  VN>   alloc += size;
  VN>   total += size;
  VN>   piece += incr;
  VN>   free(x);
  VN> } while( что-то выделялось && total <= limit );
  VN> Ладно, total - сколько всего выделялось, alloc - сколько в сумме
  VN> выделили... И ты удивляешься, что оно так себя ведёт?
  VN> Оно и должно себя так вести, при таком шаблоне выделения: ты каждый
  VN> раз просишь кусок больше, чем влезает в существующие дыры.
  VN> Естественно, будет занята почти ровно половина.
 
     Я удивляюсь потому, что в более других библиотеках (Watcom и
 Мicrosoft) этого не происходит, и кроме того, не всякий алгоритм
 выделения памяти способен довести до такого. Описанный у Кнута
 (это что в любом компиляторе 80-х годов, так?) -- приводит.
 
  KF>>    Ставить ulimit -v 65536 и запускать ./aout 2000000000 100.
  KF>> Примерно, где-то 32Мб выделяется, а половина теряется неизвестно куда.
  VN> Вполне известно куда: остаётся после освобождённых тобой областей такими
  VN> кусками, которые недостаточны для выделения любого из следующих
  VN> запрошенных.
 
    Hу так есть же дробление (фрагментация, в старой терминологии) !!!
 
  KF>> Вот тебе и фрагментация. И что интересно: это работает в linux
  KF>> (libc 2.2.5), и в pacific-c досовом (там malloc как раз на уровне
  KF>> 80-х годов прошлого века). А в Watcom-C 11-й версии не работает,
  KF>> в смысле ничего не фрагментируется.
  VN> Hа DOS? Если да, то у него как раз аллокатор неправильный;))
 
    Как это не правильный, если он более эффективно использует память?
 
  VN> Я серьёзно: это будет значить, что он не пытается минимизировать объём
  VN> выделенной памяти, оставив другим больше, а захватывает всю доступную
  VN> часть conventional memory. Или это под экстендером? Тогда он захватывает
  VN> всю дополнительную память.
 
    Да, под DPMI. Конечно, он захватывает сколько ему DOSEMU даёт. А что?
 
  VN> Hи один нормальный аллокатор в обстановке, где доступная от внешнего
  VN> источника (ОС) память может расширяться, но должна экономно использоваться,
  VN> не будет нормально работать с таким шаблоном выделения памяти.
 
    С каким ещё шаблоном?  А как быть с LCC (libc там, наверняка,
 микрософтовская) ?  Тоже ничего никуда не дробится. Впрочем, в Windows,
 как мне думается, никакого sbrk() нет и возвращённая по free память
 дейтвительно отдаётся системе. А поскольку к концу процесса идёт
 выделение уже кусками по 100кб, что значительно больше размера страницы
 (4096kb) -- можно списать всё на страничную адресацию. Hо всё равно не
 в пользу линуха -- он то так не может.
 
  KF>>    Оказывается, плохо. Только не надо говорить, что дескать в реальных
  KF>> задачах не встречается...  Меряться фрагментацией -- тоже реальная
  KF>> задача.
  VN> В таком виде как у тебя - скорее нереальная. А если она где-то реальная -
  VN> там нужно использовать другие методы распределения памяти уже на уровне
  VN> приложения.
 
    Тем не менее, случай выделения всё больших частей памяти в любой
 реальной задаче может встретится. Хотя я согласен с тем, что суммарные
 потери на неиспользуемую память в среднем невелики.
 --- [ZX]
  * Origin: Registered Linux User #204355 (2:5030/827.2)
 
 

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