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),
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"
represen
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
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 contro
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-convertin
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 ju
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
On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
> 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 ma
Peter Zijlstra wrote:
> On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
>
>> 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
On Mon, 09 Jul 2007 21:44:31 -0700 Balbir Singh wrote:
> Peter Zijlstra wrote:
> > On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
> >
> >> I am not a CLUI expert, but rounding off bytes will something that
> >> the administrators will probably complain about. Since we manage
> >> the cont
Randy Dunlap wrote:
>> Hmm.. yes.. a library routine would be nice!
>
> you mean something like lib/cmdline.c::memparse() ?
>
Excellent, one of the reasons to love Linux (there's already
code) :-)
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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 s
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.
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 us
14 matches
Mail list logo