ялро linux паникует

linux вообще себя странно ведёт когда память кончается. Его oom killer не адекватен, когда его не было(вернее, был более простой код в этом месте) просто тупо убивалась рандомная прога и всё продолжало дальше работать.

>linux вообще себя странно ведёт когда память кончается. Его oom killer не адекватен, когда его не было(вернее, был более простой код в этом месте) просто тупо убивалась рандомная прога и всё продолжало дальше работать.

в ветке 2.4 такого не помню, приложение завершалось, хотя теперь не пойму как оно это делало

настрой limits.conf

Спасибо. Попробую завтра. А дефолтные установки почему не работают?

может своп виноват ?

>uname -a
Linux halflife 2.6.24-tuxonice-r9 #3 SMP Fri Jan 2 18:34:13 MSK 2009 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux


>cat test.c
#include <malloc.h>
#include <string.h>

int main(int argc, char *argv[])
	{
	for(;;) 
		{
		void *p = malloc(1024*1024);
		memset(p,0x66,1024*1024);
		}
	}
>gcc test.c
>./a.out 
Ошибка сегментирования

     

>Linux halflife 2.6.24-tuxonice-r9 #3 SMP Fri Jan 2 18:34:13 MSK 2009 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

Образец кода не особо показателен, так как ест понемногу и захапывает физ. страницы (когда обращается). А сегфолт получается, т.к. на NULL нет проверки.
Вот если выделять сразу много, то из-за sysctl overcommit_memory настроек система может дать больше, чем есть. А при обращении будет page fault но страниц не хватит, тогда уже оом киллер за дело возмется.

да, точно - что то я херню написал. вот с проверкой.

>cat test.c

#include <malloc.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char *argv[])
	{
	int *p ;
	unsigned i;

	p = (int*)malloc(1<<31);
	if(!p)
		{
		printf("error: malloc");
		return -1;
		}

	for(i=0; i < 1<<31; i+= 1<<12)
		{
		p[i] = 0x6666;
		}

	return 0;
	}

>gcc test.c

>./a.out 
Ошибка сегментирования

*sizeof(int) в маллок вставь.

Нафиг?

он больше 4х гигов для моей системы всеравно не выделит. да и четыре не выделит.

Что нафиг? Иначе за границу в цикле вылезет.
Ну на х86 ес-но это не пройдет с 1<<31 элементов, т.к. size_t маловат.

>он больше 4х гигов для моей системы всеравно не выделит. да и четыре не выделит. Выдели просто больше, чем есть (своп отруби предварительно)

ну да, вылезет. нужно было чтото вроде char *p. 

с чаром кстати все отлично работает, и потом система замечательно тормозит

#include <malloc.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char *argv[])
	{
	char *p ;
	unsigned i;

	p = (char*)malloc(1<<31);
	if(!p)
		{
		printf("error: malloc\n");
		return -1;
		}

	for(i=0; i < (1<<31); i+= (1<<12))
		{
		p[i] = 0x66;
		}

	return 0;
	}

> Заметил если какое либо приложение выжрет всю память - ядро вешается. Помогает только холодный рестарт.

Попробуйте использовать kswapd ;)))

сделай sudo swapoff -a чтобы меньше тормозила. (в смысле, чтобы быстрее накрылась :)

наверно malloc не сработает, впрочем почему бы и не проверить

>./a.out 
error: malloc

что и требовалось доказать

Настрой kdump, дамп отошли девелоперам. Ну или хотя бы белиберду с регистрами сфотографируй и покажи. Есть люди, которые это понимают :)

>что и требовалось доказать Дык чего тут доказывать? Можно меньше выделять, естественно, сколько угодно по дефолту ядро не даст. Может, тебя там всего 32 метра...

Или почитай про overcommit.

Если хочешь, попробуй под рутом echo 1 > /proc/sys/vm/overcommit_memory

А потом запусти прогу.

вы не так тестируете. В данном случае не активизируется oom killer. Вот вы вызовите ситуацию когда ядру потребуется память а её нету. Вот тогда будут замечательные спецэффекты. Особенно под xen.

а для чего ядру понадобится память?

Наверное надо взять немного больше половины доступной памяти, а потом форкнуться. И чтобы оба процесса (потомок и родитель) одновременно забивали выделенную память. Может добьётесь появления oom-killer'а на свою голову :)

> а для чего ядру понадобится память?

для tcp-буферов например.

> Наверное надо взять немного больше половины доступной памяти, а потом форкнуться.

нет, malloc вернёт NULL и всё. и Вообще, из-за copy-on-write кол-во используемой памяти останется почти таким же т.к. оба процесса будут использовать одни и те же страницы памяти. Вот если их начать менять...

круто, но как добавить еще спецэффектов (у меня 1 гиг рама и я отключал своп)? кстати один раз убило и оперу. и еще раз кстати это сработает под оффтопом?


alex4@halflife ~ $ cat test.c
#include <malloc.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

void get_phys_pages(char *base, unsigned size)
	{
	const unsigned page_size = 1<<12;
	unsigned i;

	for(i=0; i < size; i+= (1<<12))
                {
                base[i] = 0x66;
                }
	}

int main(int argc, char *argv[])
	{	
        const unsigned alloc_size = 700 * (1<<20);
	char *p ;

	p = (char*)malloc(alloc_size);
	if(!p)
		{
		printf("error: malloc\n");
		return -1;
		}
	
	get_phys_pages(p, alloc_size);

		
	if(!fork()) 
		{
		get_phys_pages(p, alloc_size);
		}
	else
		{	
		int status;

		wait(&status);

		if(!WIFEXITED(status)) printf("child killed\n");	
		}
		
	printf("all ok\n");
	
	return 0;
	}
alex4@halflife ~ $ gcc test.c
alex4@halflife ~ $ ./a.out
child killed
all ok
alex4@halflife ~ $ 

причем дочерний процесс убивается, даже если в нем ничего не делать

> причем дочерний процесс убивается, даже если в нем ничего не делать

это как русская рулетка :). А что dmesg говорит?

> как добавить еще спецэффектов

в смысле хочешь увидеть kernel panic или что-то в этом духе? :). Проделай указанное на боевом сервере и рано или подздно что-нить упадёт т.к. не все драйвера адекватно воспринимают отказ в выделении памяти.

чтото вроде:
впрочем, после того как я закрыл оперу оно ничего не убивало, но дочерний процесс по прежнему дохнет. если убрать все выделение памяти, тогда он завершается нормально

X invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Pid: 26149, comm: X Tainted: P          2.6.27.12 #2
 [<c0151435>] oom_kill_process+0x4f/0x194
 [<c0151841>] out_of_memory+0x14e/0x17f
 [<c0153796>] __alloc_pages_internal+0x2b6/0x34c
 [<c0155130>] __do_page_cache_readahead+0x7e/0x15c
 [<c015550a>] do_page_cache_readahead+0x3d/0x47
 [<c0150cd1>] filemap_fault+0x15a/0x33d
 [<c0159ddb>] __do_fault+0x40/0x2d2
 [<c01085b4>] restore_i387+0xa5/0xe7
 [<c015b23b>] handle_mm_fault+0x259/0x4c8
 [<c0113f96>] do_page_fault+0x229/0x537
 [<c0113d6d>] do_page_fault+0x0/0x537
 [<c03aecea>] error_code+0x72/0x78
 [<c03a0000>] packet_recvmsg+0x121/0x198
 =======================
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd: 174
CPU    1: hi:  186, btch:  31 usd: 180
HighMem per-cpu:
CPU    0: hi:   42, btch:   7 usd:  35
CPU    1: hi:   42, btch:   7 usd:  39
Active:243821 inactive:1768 dirty:0 writeback:0 unstable:0
 free:3343 slab:3316 mapped:62 pagetables:539 bounce:0
DMA free:4052kB min:64kB low:80kB high:96kB active:6900kB inactive:0kB present:15804kB pages_scanned:11286 all_unreclaimable? yes
lowmem_reserve[]: 0 873 999 999
Normal free:9328kB min:3744kB low:4680kB high:5616kB active:852256kB inactive:7064kB present:894080kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 1013 1013
HighMem free:128kB min:128kB low:260kB high:396kB active:115928kB inactive:8kB present:129728kB pages_scanned:183410 all_unreclaimable? yes
lowmem_reserve[]: 0 0 0 0
DMA: 15*4kB 1*8kB 5*16kB 8*32kB 11*64kB 17*128kB 3*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4052kB
Normal: 1066*4kB 172*8kB 9*16kB 0*32kB 2*64kB 3*128kB 3*256kB 3*512kB 1*1024kB 0*2048kB 0*4096kB = 9624kB
HighMem: 7*4kB 0*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 124kB
4775 total pagecache pages
0 pages in swap cache
Swap cache stats: add 1514136, delete 1514136, find 458993/531775
Free swap  = 0kB
Total swap = 0kB
262048 pages RAM
32688 pages HighMem
3555 pages reserved
3984 pages shared
245750 pages non-shared
Out of memory: kill process 26221 (opera) score 31097 or a child
Killed process 26221 (opera)

>Вот если их начать менять...

Это и подразумевалось. Выделить память в родителе, форкнуться и начать забивать память, каждый процесс (родитель и потомок) забивает свою память. Причем, можно в цикл заполнения памяти вставить задежки типа nanosleep().

Надо будет посмотреть алгоритм OOM-killer'а в 2.6.x ядрах. В 2.4 все было просто предпочтение отдавалось пользовательским (не root) процессам с большим объемом памяти и малым runtime. Kernel-panic по этой причине не помню, а забавные эффекты были, если допустим утечка памяти была в счетной программе, которая в течении недели потихоньку кушала память, то спокойно могли быть покиляны разные сервера (httpd, postgres), а эта программа продолжала жрать память.

> Надо будет посмотреть алгоритм OOM-killer'а в 2.6.x ядрах.

заодно перепиши если время будет, оно совсем уж голимо работает :). Я часто видел ситуации когда при исчерпании памяти тачка начинала жутко тормозить, но процессы при этом не килялись.

это если в системе был своп?

я не понимаю от чего дочерний процесс дохнет. его же вроде не oom-killer убивает.

> это если в системе был своп?

это когда своп кончается :). Потом, в своп не всё можно сбросить, некоторые области памяти unswapable

> я не понимаю от чего дочерний процесс дохнет. его же вроде не oom-killer убивает.

Почему не oom-killer? Ты выводи pid-ы на экран и сравни с тем что говорит oom-killer.