Gondoltam haladok valamit ezzel is,
írtam egy 'lagmeter' programot, ami egy ciklus{ usleep(1) } jellegu cucc, es azt meri, hogy tenylegesen mennyi ideig is tart egy ciklus.
Kozben fut a 'memeater' ami triggereli a oom_killert. Cpuset felsetapolva, vm.overcommit_memory es vm.overcommit_ratio a szokasos 2/97 erteken, swap nincs, debian gyari 2.6.32-5-amd64.
Az elso futtatasnal 2.46 masodperces lagget mert a lagmeter.
A masodik futtatsnal nem mert lagot. Es a 'sar -B 1' sem laggolt szemre.
Itt egy kis dmesg reszlet:
[1048653.284355] memeater invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
[1048674.047655] Killed process 19521 (memeater)
[1048726.152085] memeater invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
[1048746.909093] Killed process 19529 (memeater)
[1048788.352354] memeater invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
[1048809.033438] Killed process 19532 (memeater)
Az elso teszt 21 masodpercig loggolt, a masodik 20 masodpercig, 21 masodpercig. Itt nincs lathato kulonbseg.
A 'memeater' ezt a 20-21 masodpercet megvarta.
Vajon ez a eloszor mert 2.46 masodperces leak az addig tartott, amig a cpu l1/l2/l3 cachebe be nem kerult valami kernbel belso info?
Akkor a kovetkezo teendo cpu cache kiurites. Ezt 48x bzip2-nek hivjak. Lacosnak pont van egy olyen progija ;)
Igen, ugy tunik, hogyha minden cpu cache valami mast tartalmaz, akkor laggol az oom_killer eseteben. Szinte teljesen merhetetlenne teszi az ugyet...
Raadasul a lagmeter hol mer, hol nem mer ertekelheto lagget. Ugy nez ki, at kellene irni pthread alapura, de legalabbis forkolosra.
Folyt. kov.