ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Mudry                         2:5020/400     30 Nov 2003  13:48:29
 To : Kirill Frolov
 Subject : Re: дефрагментация ex3
 -------------------------------------------------------------------------------- 
 

 On Sun, 30 Nov 2003, Kirill Frolov wrote:
 
 SM>> Вообще-то, для программ с утечкой памяти, действительно никакого
 SM>> свопа не напасешься.
 KF>    Это не утечка памяти, считай, что память выделялось по делу.
 
 Допустим.
 
 SM>> Я ее запустил, она поработала секунд 40, после чего была
 SM>> прибита ядром.
 KF>    В тот момент, когда она была прибита, было выделено (или не
 KF> высвобождено) всего-лишь HЕСКОЛЬКО КИЛОБАЙТ памяти. А тебе не хватило,
 
 Каких еще несколько килобайт? Откуда такая цифра?
 Впрочем, можно проверить...
 
 [x@host test]$ cat test.c
 #include <stdio.h>
 #include <stdlib.h>
 #include <math.h>
 
 int main()
 {
   long size,tsize=0;
   int i=0;
   while(1) {
     void *x, *y;
     x=malloc(10.0*rand()/RAND_MAX);
     y=malloc(size=10.0*rand()/RAND_MAX+10);
     if(x==NULL || y==NULL) break;
     free(x);
     tsize+=size;
     if((++i%0xFFFFF)==0) printf("Allocated %ld bytes\n",tsize);
   }
   exit(0);
 }
 [x@host test]$ make test
 cc     test.c   -o test
 [x@host test]$ ./test
 Allocated 15203415 bytes
 Allocated 30406695 bytes
 Allocated 45611703 bytes
 Allocated 60818570 bytes
 Allocated 76021468 bytes
 Allocated 91226694 bytes
 Allocated 106427863 bytes
 Allocated 121635044 bytes
 Allocated 136838321 bytes
 Allocated 152040224 bytes
 Allocated 167240600 bytes
 Killed
 [x@host test]$
 
 Итого, твоя программа, прежде чем была прибита, съела как минимум 160M
 По-твоему, 160000 - это HЕСКОЛЬКО?
 
 KF> наверняка, что-то около 256МБ. Разницу на 3 порядка никак не заметно?
 
 Пускаю еще раз...
 Параллелько запускаю top...
 Перед прибитием, твоя программка захватила у ядра что-то около 215 M
 Разница есть, но никак не на три порядка.
 Или у тебя компилятор такой, или библиотеки, или ядро.
 
 SM>> А дефрагментацию ОЗУ, которую ты ищешь, делают malloc() и free()
 KF>    В любой программе использующей "C-шный" механизм управления памятью
 KF> она фрагментируется.
 
 Разумеется, память фрагментируется. А как ее вообще можно
 дефрагментировать со стороны операционки? malloc() ведь никак не может
 сообщить твоей программе, что "блок NNNN я собираюсь переместить на
 адрес XXXX, поэтому не падай в корку". 
 
 Впрочем, один способ есть... Hа x86 процессорах есть сегментная
 адресация. Если каждый malloc() будет возвращать новый сегмент, то
 операционка сможет твою память спокойно и без твоего ведома перемещать
 как ей вздумается. Hе знаю, есть ли такое в Linux'е, но в какой-нибудь
 многозадачке для 80286 (типа XENIX) должно быть. В любом случае, это
 обозначает неэффективный код и потерю производительности. Кроме того,
 захват большого количества памяти мелкими блоками при помощи malloc()
 тоже обозначает неэффективный код, так как этим функциям еще надо где-то
 хранить служебную информацию о выделенных блоках памяти. Если твоей
 программе надо захватывать память именно так - ищи другой, более
 эффективный для твоей задачи алгоритм.  Ссылку на Кнута уже давали.
 -- 
 С уважением, Serg.
 mpg123 играет: /dev/zero :)
 --- ifmail v.2.15dev5.1
  * Origin: Donbass Internet Center DIPT (2:5020/400)
 
 

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