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.
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=lnk&kid3432&bid#0486&dat1642
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
