ru.linux

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

 
 On Mon, 08 Dec 03 16:04:02 +0300, Valentin Nechayev wrote:
 
  VN> А какие алгоритмы ты предлагаешь? Собственно здесь любой доведёт до того
  VN> же, если будет пытаться каждый раз просить памяти как можно меньше,
  VN> а не запрашивать сначала ведро и из него по капле давать.
 
    Точно любой?  Возможно...
 
  KF>>    Да, под DPMI. Конечно, он захватывает сколько ему DOSEMU даёт. А что?
  VN> Вот это и плохо. Представь себе, что из-под себя ему надо какую-то
  VN> другую программу запустить. Что он будет делать? Hарезать страницы из
  VN> собственной памяти, выкраивая каждую страничку, чтобы набрать память
 
    Hу это если внутри dosemu. А снаружи, вывод ps показывает RSS
 примерно столько, сколько там внутри выделено. Hу это опять-же
 страничная адресация сказывается, как я думаю.
 
  KF>> выделение уже кусками по 100кб, что значительно больше размера страницы
  KF>> (4096kb) -- можно списать всё на страничную адресацию. Hо всё равно не
  KF>> в пользу линуха -- он то так не может.
  VN> Я думаю, может. Если разрешить. Попробуй подкрутить mallopt'ом
  VN> размер, начиная с которого начинает использоваться mmap().
  VN> Hо слишком занижать его нельзя.
 
    Вот теперь Винда-Линух -- 1:1, почти.
 
 $ ulimit -v 32768
 $ ./a.out 200000000
 mallopt(M_MMAP_THRESHOLD, 4096) -> 1
 can't allocate 54701 bytes
 limit=200000000, piece=54701, incr=50
 total=59843989, allocated=29894644
 
 >     ^^^^^^^^
 > это говорит как раз о повторном использовании освобождённой памяти
 >
 
 mallinfo:
 arena = 336392 bytes allocated with sbrk
 
 >       ^^^^^^
 > причём если M_MAP_THRESHOLD = 8kb уже мегабайт где-то, а 16кб -- 5Мб.  
 > аналогично, уже при 16кб потери где-то 5Мб.
 
 ordblks = 336392 chunks not in use
 smblks = 0 (unused field)
 hblks = 1013 chunks allocated with mmap
 hblkhd = 31907840 bytes allocated with mmap
 usmblks = 0 (unused field)
 fsmblks = 0 (unused field)
 uordblks = 166792 bytes occupied by chunks handed out by malloc
 fordblks = 169600 bytes occupied by free (not in use) chunks
 keepcost = 2808 bytes, size of chunk at the top of address space
 
    Совсем другое дело! (Hо нарезать-то память на куски по <4kb всё равно
 можно...)
 И почему такая рулезная функция отключена по умолчанию?  Получается, с
 одной стороны линух вроде как может, а с другой стороны, практически
 никакие программы этим никак не пользуются.
 --- [ZX]
  * Origin: Registered Linux User #204355 (2:5030/827.2)
 
 

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