Hi Valérie,
[EMAIL PROTECTED] wrote:
Hi Maeda,
I tried to reproduce your problem on my machine but I didn' succeed. So
I'd need more information.
What size is the swap partition on your machine ?
I attached about 4GB swap partitions in total on the machine.
# swapon -s
Filename Type Size Used
Priority
/dev/sdb2 partition 1051616 150992 -1
/dev/sdc2 partition 1052160 0 -2
/dev/mapper/VolGroup00-LogVol01 partition 2031584 0 -3
Could you give me also the output of 'cat /proc/vmstat' and 'cat
/proc/meminfo' when the processes hang up ?
Here are the contents of /proc/vmstat and /proc/meminfo during hang up.
# cat /proc/vmstat
nr_dirty 606
nr_writeback 0
nr_unstable 0
nr_page_table_pages 445
nr_mapped 8344
nr_slab 4260
pgpgin 29965197
pgpgout 15652456
pswpin 1580993
pswpout 928948
pgalloc_high 0
pgalloc_normal 9441882
pgalloc_dma 102
pgfree 9642912
pgactivate 783608
pgdeactivate 2815391
pgfault 26461426
pgmajfault 476018
pgrefill_high 0
pgrefill_normal 9022117
pgrefill_dma 0
pgsteal_high 0
pgsteal_normal 2346974
pgsteal_dma 0
pgscan_kswapd_high 0
pgscan_kswapd_normal 6228791
pgscan_kswapd_dma 0
pgscan_direct_high 0
pgscan_direct_normal 0
pgscan_direct_dma 0
pginodesteal 0
slabs_scanned 0
kswapd_steal 2346974
kswapd_inodesteal 0
pageoutrun 0
allocstall 0
pgrotated 942793
nr_bounce 0
# cat /proc/meminfo
MemTotal: 4076448 kB
MemFree: 3213472 kB
Buffers: 61152 kB
Cached: 373584 kB
SwapCached: 39632 kB
Active: 502000 kB
Inactive: 53664 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 4076448 kB
LowFree: 3213472 kB
SwapTotal: 4135360 kB
SwapFree: 3984368 kB
Dirty: 9696 kB
Writeback: 0 kB
Mapped: 133504 kB
Slab: 68144 kB
CommitLimit: 6173584 kB
Committed_AS: 290672 kB
PageTables: 7120 kB
VmallocTotal: 137430532096 kB
VmallocUsed: 17872 kB
VmallocChunk: 137430513904 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 262144 kB
Thanks,
MAEDA Naoaki
Thanks,
Valérie
Hi Valérie,
[EMAIL PROTECTED] wrote:
Hi Maeda,
the issue is due to the fact that the value of the guarantee is equal to
the value of the limit for this class.
The 'limit' is the maximum number of pages this class can get; for the
memory controller, it is a hard limit. Pages attached to a class that is
below its guarantee can not be reclaimed. So in your case, no pages of
the
class can be reclaimed when the class reached its limit.
I think that this configuration (guarantee=limit) should not be allowed
and should be controlled at configuration time.
Oh! I didn't know that. However, it still happens even if guarantee = 0.
Probably there is another reason.
The following is the stats of the class on guarantee=0 during hung.
--------- Memory Resource stats start ---------
Maximum of shrink ever called by the class = 6916
Maximum of pages ever used by the class = 5118
Maximum of pages ever used into the ckrm zone index 0 = 0
Maximum of pages ever used into the ckrm zone index 1 = 5118
Number of pages used(including pages lent to children): 5066
Number of pages guaranteed: -2
Maximum limit of pages: 5062
Total number of pages available(after serving guarantees to children): -2
Number of pages lent to children: 0
Number of pages borrowed from the parent: 5066
---------- Memory Resource stats end ----------
The following is the process list whose status was D.
Not only did the processes belonged to the kernbench hang up
but also pdflush, kswapd and kjournald hung up on D state.
It is not a healthy condition.
[EMAIL PROTECTED] ~]$ ps -lea | grep D
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
1 D 0 234 11 0 75 0 - 0 start_ ? 00:00:00 pdflush
1 D 0 235 1 0 75 0 - 0 start_ ? 00:01:21 kswapd0
1 D 0 3867 1 0 75 0 - 0 journa ? 00:00:00
kjournald
0 D 500 2132 2131 0 78 0 - 5433 blk_co pts/2 00:00:00 cc1
0 D 500 2215 2214 0 78 0 - 5430 blk_co pts/2 00:00:01 cc1
0 D 500 2313 2312 0 78 0 - 4626 blk_co pts/2 00:00:00 cc1
0 D 500 2374 2373 0 78 0 - 4607 blk_co pts/2 00:00:00 cc1
0 D 500 2385 2384 0 78 0 - 5042 start_ pts/2 00:00:00 cc1
0 D 500 2386 2384 0 78 0 - 2996 blk_co pts/2 00:00:00 as
0 D 500 2393 2368 0 78 0 - 208 start_ pts/2 00:00:00 fixdep
0 D 500 2398 2397 0 78 0 - 3342 lookup pts/2 00:00:00 cc1
0 D 500 2399 2397 0 78 0 - 2964 blk_co pts/2 00:00:00 as
Thanks,
MAEDA Naoaki
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
