Display the current usage and limit in a more user friendly manner. Number
of pages can be confusing if the page size is different. Some systems
can choose a page size of 64KB.
NOTE: Values shown in MB and GB could be rounded off.
Sample display
:~ # cat /container/rss_limit
17179869183 (GB), 9223372036854775807 pages
:~ # cat /container/rss_usage
36 (MB), 9220 pages
:~ #
Signed-off-by: Balbir Singh <[email protected]>
---
include/linux/res_counter.h | 6 ++++++
kernel/res_counter.c | 27 +++++++++++++++++++++++----
2 files changed, 29 insertions(+), 4 deletions(-)
diff -puN kernel/res_counter.c~rss-ui-display-kdb kernel/res_counter.c
--- linux-2.6.22-rc24-mm2/kernel/res_counter.c~rss-ui-display-kdb 2007-06-20 20:15:46.000000000 +0530
+++ linux-2.6.22-rc24-mm2-balbir/kernel/res_counter.c 2007-06-20 21:12:29.000000000 +0530
@@ -61,7 +61,8 @@ void res_counter_uncharge(struct res_cou
}
-static inline unsigned long *res_counter_member(struct res_counter *cnt, int member)
+static inline unsigned long *res_counter_member(struct res_counter *cnt,
+ int member, int *format_mem)
{
switch (member) {
case RES_USAGE:
@@ -69,6 +70,7 @@ static inline unsigned long *res_counter
case RES_LIMIT:
return &cnt->limit;
case RES_FAILCNT:
+ *format_mem = 0;
return &cnt->failcnt;
};
@@ -81,10 +83,26 @@ ssize_t res_counter_read(struct res_coun
{
unsigned long *val;
char buf[64], *s;
+ int format_mem = 1;
+ unsigned long val_kb = 0, val_mb = 0, val_gb = 0;
s = buf;
- val = res_counter_member(cnt, member);
- s += sprintf(s, "%lu\n", *val);
+ val = res_counter_member(cnt, member, &format_mem);
+ /*
+ * NOTE: GB and MB values might be rounded off
+ */
+ if (format_mem) {
+ val_gb = (*val << PAGE_SHIFT) >> GB_SHIFT;
+ val_mb = (*val << PAGE_SHIFT) >> MB_SHIFT;
+ val_kb = (*val << PAGE_SHIFT) >> KB_SHIFT;
+ if (val_gb)
+ s += sprintf(s, "%lu (GB), %lu pages\n", val_gb, *val);
+ else if (val_mb)
+ s += sprintf(s, "%lu (MB), %lu pages\n", val_mb, *val);
+ else
+ s += sprintf(s, "%lu (KB), %lu pages\n", val_kb, *val);
+ } else
+ s += sprintf(s, "%lu\n", *val);
return simple_read_from_buffer((void __user *)userbuf, nbytes,
pos, buf, s - buf);
}
@@ -95,6 +113,7 @@ ssize_t res_counter_write(struct res_cou
int ret;
char *buf, *end;
unsigned long tmp, *val;
+ int nop;
buf = kmalloc(nbytes + 1, GFP_KERNEL);
ret = -ENOMEM;
@@ -111,7 +130,7 @@ ssize_t res_counter_write(struct res_cou
if (*end != '\0')
goto out_free;
- val = res_counter_member(cnt, member);
+ val = res_counter_member(cnt, member, &nop);
*val = tmp;
ret = nbytes;
out_free:
diff -puN include/linux/res_counter.h~rss-ui-display-kdb include/linux/res_counter.h
--- linux-2.6.22-rc24-mm2/include/linux/res_counter.h~rss-ui-display-kdb 2007-06-20 20:15:46.000000000 +0530
+++ linux-2.6.22-rc24-mm2-balbir/include/linux/res_counter.h 2007-06-20 21:01:57.000000000 +0530
@@ -13,6 +13,12 @@
#include <linux/container.h>
+#ifndef KB_SHIFT
+#define KB_SHIFT 10
+#define MB_SHIFT 20
+#define GB_SHIFT 30
+#endif
+
/*
* the core object. the container that wishes to account for some
* resource may include this counter into its structures and use
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
On 6/20/07, Balbir Singh <[email protected]> wrote:
>
>
> Display the current usage and limit in a more user friendly manner. Number
> of pages can be confusing if the page size is different. Some systems
> can choose a page size of 64KB.
I'm not sure that's such a great idea. "Human-friendly"
representations would make programmatic parsing harder.
What's wrong with just showing counts in bytes in the control files?
Paul
Paul Menage wrote:
> On 6/20/07, Balbir Singh <[email protected]> wrote:
>>
>>
>> Display the current usage and limit in a more user friendly manner.
>> Number
>> of pages can be confusing if the page size is different. Some systems
>> can choose a page size of 64KB.
>
> I'm not sure that's such a great idea. "Human-friendly"
> representations would make programmatic parsing harder.
>
> What's wrong with just showing counts in bytes in the control files?
Nothing wrong, but currently they are shown in "natural" points, i.e. in
those that the controller accounts them in. For RSS controller the natural
point is "page", but auto-converting them from pages to bytes is wrong, as
not all the controllers account in pages. I think that the better way is
to show the value in the internal units and specify (somehow) what these
units are. The userspace then can read them and convert accordingly.
> Paul
Thanks,
Pavel
On 6/21/07, Pavel Emelianov <[email protected]> wrote:
>
> Nothing wrong, but currently they are shown in "natural" points, i.e. in
> those that the controller accounts them in. For RSS controller the natural
> point is "page", but auto-converting them from pages to bytes is wrong, as
> not all the controllers account in pages.
This exposes more implementation detail than I think is good.
Something like a memory controller should use a more abstract
interface like bytes, and do the conversion to/from its internal
"natural" units like pages internally. E.g. the example cpu accounting
controller that I included with my patch set reports usage in
milliseconds, even though it counts internally in jiffies.
Paul
On 6/22/07, Paul Menage <[email protected]> wrote:
> On 6/21/07, Pavel Emelianov <[email protected]> wrote:
> >
> > Nothing wrong, but currently they are shown in "natural" points, i.e. in
> > those that the controller accounts them in. For RSS controller the natural
> > point is "page", but auto-converting them from pages to bytes is wrong, as
> > not all the controllers account in pages.
>
> This exposes more implementation detail than I think is good.
> Something like a memory controller should use a more abstract
> interface like bytes, and do the conversion to/from its internal
> "natural" units like pages internally. E.g. the example cpu accounting
> controller that I included with my patch set reports usage in
> milliseconds, even though it counts internally in jiffies.
>
Hi, Paul,
Bytes are too fine grained. Do we also accept the input in bytes? kB
are probably the best, but then with the limit set to LONG_MAX, kB
wrap around (if the input is in units of pages) on 64 bit machines
(the sameapplies to bytes as well).
The problem with input in bytes is that the user will have to ensure
that the input is
a multiple of page size, which implies that she would need to use the
calculator every time.
On 6/22/07, Balbir Singh <[email protected]> wrote:
>
> The problem with input in bytes is that the user will have to ensure
> that the input is
> a multiple of page size, which implies that she would need to use the
> calculator every time.
>
Having input in bytes seems pretty natural to me. Why not just have
the RSS controller round the input to the nearest page (or whatever
granularity of memory the controller is able to limit at)?
Paul
Paul Menage wrote:
> On 6/22/07, Balbir Singh <[email protected]> wrote:
>
>>The problem with input in bytes is that the user will have to ensure
>>that the input is
>>a multiple of page size, which implies that she would need to use the
>>calculator every time.
>>
>
>
> Having input in bytes seems pretty natural to me. Why not just have
> the RSS controller round the input to the nearest page (or whatever
> granularity of memory the controller is able to limit at)?
totally agree with Paul.
Kirill
Kirill Korotaev wrote:
> Paul Menage wrote:
>> On 6/22/07, Balbir Singh <[email protected]> wrote:
>>
>>> The problem with input in bytes is that the user will have to ensure
>>> that the input is
>>> a multiple of page size, which implies that she would need to use the
>>> calculator every time.
>>>
>>
>> Having input in bytes seems pretty natural to me. Why not just have
>> the RSS controller round the input to the nearest page (or whatever
>> granularity of memory the controller is able to limit at)?
>
> totally agree with Paul.
>
> Kirill
>
Kirill
If someone assigns a rss_limit of 1 byte and sees a usage of 1 page,
won't that be confusing. But having said that it's not a big
change, it should be easy to accommodate.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
Balbir Singh wrote:
> Kirill Korotaev wrote:
>
>>Paul Menage wrote:
>>
>>>On 6/22/07, Balbir Singh <[email protected]> wrote:
>>>
>>>
>>>>The problem with input in bytes is that the user will have to ensure
>>>>that the input is
>>>>a multiple of page size, which implies that she would need to use the
>>>>calculator every time.
>>>>
>>>
>>>Having input in bytes seems pretty natural to me. Why not just have
>>>the RSS controller round the input to the nearest page (or whatever
>>>granularity of memory the controller is able to limit at)?
>>
>>totally agree with Paul.
>>
>>Kirill
>>
>
> Kirill
>
> If someone assigns a rss_limit of 1 byte and sees a usage of 1 page,
> won't that be confusing. But having said that it's not a big
> change, it should be easy to accommodate.
Well, from my expirience pages are hardly understandable by people.
So bytes are always better and more convinient for non-programmers.
Rounding is not that big issue, since people still get the result
they expect (unlike to the case when they mess up with the page size).
Thanks,
Kirill
P.S. 1 byte limit is not that common :)
Paul Menage wrote:
> On 6/22/07, Balbir Singh <[email protected]> wrote:
>>
>> The problem with input in bytes is that the user will have to ensure
>> that the input is
>> a multiple of page size, which implies that she would need to use the
>> calculator every time.
>>
>
> Having input in bytes seems pretty natural to me. Why not just have
> the RSS controller round the input to the nearest page (or whatever
> granularity of memory the controller is able to limit at)?
>
> Paul
Hi, Paul,
I am not a CLUI expert, but rounding off bytes will something that
the administrators will probably complain about. Since we manage
the controller memory in pages, it might be the easiest unit to use.
The output is totally different matter.
Having said that, I am not opposed to your suggestion, I'll see if
I can find good CLUI guidelines.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL