ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     05 Dec 2003  13:29:33
 To : Kirill Frolov
 Subject : Re: дефрагментация ex3
 -------------------------------------------------------------------------------- 
 

 
 >>> Kirill Frolov wrote:
 
  VN>> А называется оно - ты выжрал память мелкими кусками.
 KF>    Память выжрата мелкими кусками, или блоки на диске (тоже память...)
 KF> теми же самыми кусками -- принципиальной разницы нет.
 
 Собственно фрагментацию-то ты не показал. А съесть какое-то количество
 памяти мелкими кусками - нормальная рабочая ситуация.
 
  VN>> P.S. Ещё и программа сляпана на кривой коленке или наскоро переделана
  VN>> из чего-то другого так, что показывает совсем не то, что нужно.
 KF>    Я её из книжки передрал. В линухе эта программа не работает как
 KF> надо. Догадываюсь, что линух имеет malloc() сильно отличный чем описан у
 KF> того-же Кнута (там фрагментируется "на ура").
 
 Я не знаю, что ты откуда передирал и кто чего испортил, но в таком виде она
 просто ничего не будет показывать - в ней логические ошибки.
 Показывало бы, например, вот такое:
 
 int main() {
   int cnt = 0, got = 0;
   for(;;) {
     if( malloc(1) == 0 ) err( 1, "malloc" );
     ++got;
     if( ++cnt >= 100000 ) { cnt = 0; printf( "allocated %d bytes\n", got ); }
   }
 }
 
 здесь выделяем память кусками по байту. Hадо перед запуском установить
 ulimit'ом сколько она может выжрать (например, 200M) и когда остановится -
 сравнить сколько выдала с допустимым размером. Убрать пару процентов на
 управляющие структуры кучи и мегабайт-два на программу плюс libc.
 По тому, что я слышал про glibc malloc, он такое отрабатывает хорошо.
 Вместо выделения по 1 байту можно брать другие значения, какие-нибудь
 большие и некрасивые. Hапример, выделение по 2050 байт, вероятно, даст
 страницу на такой блок с неиспользованием хвоста страницы, и эффективность
 использования будет около 50%.
 -netch-
 --- ifmail v.2.15dev5.1
  * Origin: Dark side of coredump (2:5020/400)
 
 

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