On Sat, 2006-01-28 at 08:58 +0900, MAEDA Naoaki wrote: > 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.
certainly not... does the state change at all. Can you see it with top. Just wondering whether the limit is too low, which makes the pages to be swapped so very often. > [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 > > > > > Regards, > > Valérie > > > > > > > > Hi Valérie, > > > > Valerie Clement wrote: > >> The memory resource controller against 2.6.15 is also available on the > >> project web site. It is just an update for a new kernel version. > > > > I am trying to run the kernbench with the memory resource controller > > enabled, but the processes in the kernbench hang up in the case of > > shrinking the class the kernbench belongs to being called massively. > > > > At that time, the processes in the kernbench were either S or D state, > > and none of them became R state. However, the processes belonged to > > the other class worked normally except the fact that sync command > > never returned. > > > > The following was the stats of the class the kernbench belonged to while > > the hung up was happening. Memory limit and guarantee were intentionally > > set to small values in order to put stress on the memory resource > > controller. In that case, they were set to about 80MB. > > > > --------- Memory Resource stats start --------- > > Maximum of shrink ever called by the class = 2636 > > Maximum of pages ever used by the class = 5112 > > Maximum of pages ever used into the ckrm zone index 0 = 0 > > Maximum of pages ever used into the ckrm zone index 1 = 5112 > > Number of pages used(including pages lent to children): 5066 > > Number of pages guaranteed: 5057 > > Maximum limit of pages: 5057 > > Total number of pages available(after serving guarantees to children): > > 5057 > > Number of pages lent to children: 0 > > Number of pages borrowed from the parent: 9 > > ---------- Memory Resource stats end ---------- > > > > After canceling the kernbench by SIGINTR, the class went back to > > the normal state. > > > > Do you have any clue regarding the issue? > > > > 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&kid3432&bid#0486&dat1642 > _______________________________________________ > ckrm-tech mailing list > https://lists.sourceforge.net/lists/listinfo/ckrm-tech > -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - [EMAIL PROTECTED] | .......you may get it. ---------------------------------------------------------------------- ------------------------------------------------------- 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&kid3432&bid#0486&dat1642 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
