On Wed, 26 Sep 2007, Balbir Singh wrote:
Yes, I prefer 0 as well and had that in a series in the Lost World
of my earlier memory/RSS controller patches. I feel now that 0 is
a bit confusing, we don't use 0 to mean unlimited, unless we
treat the memory.limit_in_bytes value as boolean. 0 is
On Wed, 26 Sep 2007, KAMEZAWA Hiroyuki wrote:
#define RES_COUNTER_INIFINITY (~0ULL)
or some nice name
Why do we need this at all? We can simply push -1 there and be happy.
Hm, can this work now ?
==
echo -1 /cgroup/memory.limit_in_bytes
==
Or users have to do
On Tue, 25 Sep 2007, Paul Menage wrote:
If I echo -n 8191 memory.limit_in_bytes, I'm still only going to be able
to charge one page on my x86_64. And then my program's malloc(5000) is
going to fail, which leads to the inevitable head scratching.
This is a very unrealistic argument.
On Tue, 25 Sep 2007, Paul Menage wrote:
nit pick, should be memory.limit_in_bytes
Can we reconsider this? I do think that plain limit would enable you
to have a more consistent API across all resource counters users.
Why aren't limits expressed in kilobytes? All architectures have
On Tue, 25 Sep 2007, Paul Menage wrote:
If you're fine with rounding up to the nearest page, then what's the point
of exposing it as a number of bytes?? You'll never get a granularity
finer than a kilobyte.
API != implementation.
Having the limit expressed and configurable in bytes
On Tue, 25 Sep 2007, Paul Menage wrote:
It doesn't matter. When I cat my cgroup's memory.limit (or
memory.limit_in_bytes), I should see the total number of bytes that my
applications are allowed. That's not an unrealistic expectation of a
system that is expressly designed to control my
KAMEZAWA Hiroyuki wrote:
On Wed, 26 Sep 2007 00:51:59 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
David Rientjes wrote:
Yes, I prefer 0 as well and had that in a series in the Lost World
of my earlier memory/RSS controller patches. I feel now that 0 is
a bit confusing, we don't use 0 to
Pavel Emelyanov wrote:
KAMEZAWA Hiroyuki wrote:
On Wed, 26 Sep 2007 00:51:59 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
David Rientjes wrote:
Yes, I prefer 0 as well and had that in a series in the Lost World
of my earlier memory/RSS controller patches. I feel now that 0 is
a bit
Balbir Singh wrote:
Pavel Emelyanov wrote:
KAMEZAWA Hiroyuki wrote:
On Wed, 26 Sep 2007 00:51:59 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
David Rientjes wrote:
Yes, I prefer 0 as well and had that in a series in the Lost World
of my earlier memory/RSS controller patches. I feel now that
KAMEZAWA Hiroyuki wrote:
just for a RFC.
When I use memory controller, I notice that memory.limit_in_bytes shows
just very big number, if unlimited.
A user(or tool) has to know that the big number(LLONG_MAX) means unlimted.
IMHO, some interface which allows users to specify unlimited
On Tue, 25 Sep 2007 16:19:18 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
Hi, Kamezawa-San,
Hi,
Your changes make sense, but not CLUI (Command Line Usage) sense.
1. The problem is that when we mix strings with numbers, tools that
parse/use get confused and complicated
yes, maybe.
2.
KAMEZAWA Hiroyuki wrote:
On Tue, 25 Sep 2007 16:19:18 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
Hi, Kamezawa-San,
Hi,
Your changes make sense, but not CLUI (Command Line Usage) sense.
1. The problem is that when we mix strings with numbers, tools that
parse/use get confused and
Balbir Singh wrote:
KAMEZAWA Hiroyuki wrote:
On Tue, 25 Sep 2007 16:19:18 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
Hi, Kamezawa-San,
Hi,
Your changes make sense, but not CLUI (Command Line Usage) sense.
1. The problem is that when we mix strings with numbers, tools that
parse/use
Pavel Emelyanov wrote:
Balbir Singh wrote:
KAMEZAWA Hiroyuki wrote:
On Tue, 25 Sep 2007 16:19:18 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
Hi, Kamezawa-San,
Hi,
Your changes make sense, but not CLUI (Command Line Usage) sense.
1. The problem is that when we mix strings with numbers,
Balbir Singh wrote:
Pavel Emelyanov wrote:
Balbir Singh wrote:
KAMEZAWA Hiroyuki wrote:
On Tue, 25 Sep 2007 16:19:18 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
Hi, Kamezawa-San,
Hi,
Your changes make sense, but not CLUI (Command Line Usage) sense.
1. The problem is that when we mix
On Tue, 25 Sep 2007 19:14:53 +0400
Pavel Emelyanov [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote:
On Tue, 25 Sep 2007 17:34:00 +0400
Pavel Emelyanov [EMAIL PROTECTED] wrote:
Well, no container may have the ULLMAX (or what is it?) bytes
touched/allocated :) So I don't see any need in a
David Rientjes wrote:
On Wed, 26 Sep 2007, KAMEZAWA Hiroyuki wrote:
#define RES_COUNTER_INIFINITY (~0ULL)
or some nice name
Why do we need this at all? We can simply push -1 there and be happy.
Hm, can this work now ?
==
echo -1 /cgroup/memory.limit_in_bytes
==
Or users
On 9/25/07, Balbir Singh [EMAIL PROTECTED] wrote:
nit pick, should be memory.limit_in_bytes
Can we reconsider this? I do think that plain limit would enable you
to have a more consistent API across all resource counters users.
I realise that there's the issue that if someone's never heard of
On 9/25/07, David Rientjes [EMAIL PROTECTED] wrote:
If I echo -n 8191 memory.limit_in_bytes, I'm still only going to be able
to charge one page on my x86_64. And then my program's malloc(5000) is
going to fail, which leads to the inevitable head scratching.
This is a very unrealistic
On 9/25/07, David Rientjes [EMAIL PROTECTED] wrote:
It doesn't matter. When I cat my cgroup's memory.limit (or
memory.limit_in_bytes), I should see the total number of bytes that my
applications are allowed. That's not an unrealistic expectation of a
system that is expressly designed to
On 9/25/07, David Rientjes [EMAIL PROTECTED] wrote:
If you're fine with rounding up to the nearest page, then what's the point
of exposing it as a number of bytes?? You'll never get a granularity
finer than a kilobyte.
API != implementation.
So by expressing it in terms of bytes instead
On 9/25/07, David Rientjes [EMAIL PROTECTED] wrote:
Having the limit expressed and configurable in bytes suggests that it can
be defined on that granularity which is obviously wrong.
One of the other options suggested was that you can write a value in
bytes, and the value you can read back
22 matches
Mail list logo
