Hi Chandra,

Chandra Seetharaman wrote:
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.

I intentionally set very low limit value. Slow down may happen.
However, it seems that there is no swap activity during hang.

[EMAIL PROTECTED] ~]$ vmstat 5

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 8 150992 3429280 56688 158272 234 138 277 142 5 25 1 0 33 66 0 8 150992 3429280 56704 158256 0 0 0 7 2003 415 0 0 50 50 0 8 150992 3429280 56704 158256 0 0 0 0 2002 411 0 0 50 50 0 8 150992 3429280 56704 158256 0 0 0 2 2002 413 0 0 50 50 0 8 150992 3429280 56704 158256 0 0 0 0 2002 411 0 0 50 50 0 8 150992 3429280 56704 158256 0 0 0 0 2005 411 0 0 50 50

There is almost no I/O activity also.

[EMAIL PROTECTED] ~]$ iostat 5
Linux 2.6.15-f0.4-v0.3-mem (tiger4)     01/28/2006
avg-cpu:  %user   %nice    %sys %iowait   %idle

            0.62    0.00    0.15   65.95   33.28

 Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
 sda               1.60       118.65         5.27    6383188     283480
 sdb              13.90       965.65       558.86   51950212   30065608
 sdc               1.77        27.20         5.55    1463130     298624
 md0               5.07        57.10        11.86    3071778     637896

 avg-cpu:  %user   %nice    %sys %iowait   %idle
            0.01    0.00    0.02   50.00   49.98

 Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
 sda               0.40         0.00        19.20          0         96
 sdb               0.00         0.00         0.00          0          0
 sdc               0.00         0.00         0.00          0          0
 md0               0.00         0.00         0.00          0          0

 avg-cpu:  %user   %nice    %sys %iowait   %idle
            0.00    0.00    0.00   50.00   50.00

 Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
 sda               0.00         0.00         0.00          0          0
 sdb               0.00         0.00         0.00          0          0
 sdc               0.00         0.00         0.00          0          0
 md0               0.00         0.00         0.00          0          0

 avg-cpu:  %user   %nice    %sys %iowait   %idle
            0.00    0.00    0.00   50.00   50.00

 Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
 sda               0.00         0.00         0.00          0          0
 sdb               0.00         0.00         0.00          0          0
 sdc               0.00         0.00         0.00          0          0
 md0               0.00         0.00         0.00          0          0

In addition, maximum of shrink ever called by the class was not changed
at least for several hours.

 --------- 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 ----------



[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





-------------------------------------------------------
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

Reply via email to