ru.linux

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

 >>> Kirill Frolov wrote: 
 
  VN>> Ладно, total - сколько всего выделялось, alloc - сколько в сумме
  VN>> выделили... И ты удивляешься, что оно так себя ведёт?
  VN>> Оно и должно себя так вести, при таком шаблоне выделения: ты каждый
  VN>> раз просишь кусок больше, чем влезает в существующие дыры.
  VN>> Естественно, будет занята почти ровно половина.
 KF>     Я удивляюсь потому, что в более других библиотеках (Watcom и
 KF> Мicrosoft) этого не происходит, и кроме того, не всякий алгоритм
 KF> выделения памяти способен довести до такого. Описанный у Кнута
 KF> (это что в любом компиляторе 80-х годов, так?) -- приводит.
 
 А какие алгоритмы ты предлагаешь? Собственно здесь любой доведёт до того
 же, если будет пытаться каждый раз просить памяти как можно меньше,
 а не запрашивать сначала ведро и из него по капле давать.
 Политика вида "первый подходящий", "наиболее подходящий" и т.п.,
 на это никак не влияют. Так же как и формат управляющих структур (которые
 сейчас практически во всех аллокаторах - деревья, а не списки).
 
  KF>>>    Ставить ulimit -v 65536 и запускать ./aout 2000000000 100.
  KF>>> Примерно, где-то 32Мб выделяется, а половина теряется неизвестно куда.
  VN>> Вполне известно куда: остаётся после освобождённых тобой областей такими
  VN>> кусками, которые недостаточны для выделения любого из следующих
  VN>> запрошенных.
 KF>    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>> всю дополнительную память.
 KF>    Да, под DPMI. Конечно, он захватывает сколько ему DOSEMU даёт. А что?
 
 Вот это и плохо. Представь себе, что из-под себя ему надо какую-то
 другую программу запустить. Что он будет делать? Hарезать страницы из
 собственной памяти, выкраивая каждую страничку, чтобы набрать память
 для этого?
 Памяти должно быть занято столько, сколько нужно.
 
  VN>> Hи один нормальный аллокатор в обстановке, где доступная от внешнего
  VN>> источника (ОС) память может расширяться, но должна экономно
  VN>> использоваться,
  VN>> не будет нормально работать с таким шаблоном выделения памяти.
 KF>    С каким ещё шаблоном?  А как быть с LCC (libc там, наверняка,
 KF> микрософтовская) ?  Тоже ничего никуда не дробится.
 
 Этого не видел, ничего сказать не могу.
 
 KF> Впрочем, в Windows,
 KF> как мне думается, никакого sbrk() нет и возвращённая по free память
 KF> дейтвительно отдаётся системе.
 
 Возможно. GlobalAlloc/GlobalFree берут кусками из достаточно произвольного
 места.
 В этом плане надо было бы сравнивать с malloc'ом, который работает через
 mmap, а не через sbrk.
 
 KF> А поскольку к концу процесса идёт
 KF> выделение уже кусками по 100кб, что значительно больше размера страницы
 KF> (4096kb) -- можно списать всё на страничную адресацию. Hо всё равно не
 KF> в пользу линуха -- он то так не может.
 
 Я думаю, может. Если разрешить. Попробуй подкрутить mallopt'ом
 размер, начиная с которого начинает использоваться mmap().
 Hо слишком занижать его нельзя.
 -netch-
 --- ifmail v.2.15dev5.1
  * Origin: Dark side of coredump (2:5020/400)
 
 

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