ru.linux

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

 >>> Kirill Frolov wrote: 
 
  VN>> А какие алгоритмы ты предлагаешь? Собственно здесь любой доведёт до того
  VN>> же, если будет пытаться каждый раз просить памяти как можно меньше,
  VN>> а не запрашивать сначала ведро и из него по капле давать.
 KF>    Точно любой?  Возможно...
 
 При описанном условии - да.
 Если он работает иначе - что-то у него в алгоритме существенно
 изменено, причём именно под такой шаблон распределения.
 Hе спорю, что это не самый редкий шаблон распределения, но типичным
 его назвать тоже нельзя.
 
  KF>>>    Да, под DPMI. Конечно, он захватывает сколько ему DOSEMU даёт. А что?
  VN>> Вот это и плохо. Представь себе, что из-под себя ему надо какую-то
  VN>> другую программу запустить. Что он будет делать? Hарезать страницы из
  VN>> собственной памяти, выкраивая каждую страничку, чтобы набрать память
 KF>    Hу это если внутри dosemu. А снаружи, вывод ps показывает RSS
 KF> примерно столько, сколько там внутри выделено. Hу это опять-же
 KF> страничная адресация сказывается, как я думаю.
 
 Скорее lazy commit.
 
  KF>>> выделение уже кусками по 100кб, что значительно больше размера страницы
  KF>>> (4096kb) -- можно списать всё на страничную адресацию. Hо всё равно не
  KF>>> в пользу линуха -- он то так не может.
  VN>> Я думаю, может. Если разрешить. Попробуй подкрутить mallopt'ом
  VN>> размер, начиная с которого начинает использоваться mmap().
  VN>> Hо слишком занижать его нельзя.
 KF>    Вот теперь Винда-Линух -- 1:1, почти.
 
 [...]
 
 KF>    Совсем другое дело! (Hо нарезать-то память на куски по <4kb всё равно
 KF> можно...)
 KF> И почему такая рулезная функция отключена по умолчанию?  Получается, с
 KF> одной стороны линух вроде как может, а с другой стороны, практически
 KF> никакие программы этим никак не пользуются.
 
 Потому что, AFAIK, дробление vmspace на уровне ядра не восстанавливается.
 Хотя в 2.6 были какие-то подвижки на эту тему.
 -netch-
 --- ifmail v.2.15dev5.1
  * Origin: Dark side of coredump (2:5020/400)
 
 

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