These are the signed equivalents of the read_u64/write_u64 methods
Signed-off-by: Paul Menage [EMAIL PROTECTED]
---
include/linux/cgroup.h |8
kernel/cgroup.c| 38 --
2 files changed, 36 insertions(+), 10 deletions(-)
Index:
These patches add cgroups read_s64 and write_s64 control file methods
(the signed equivalent of read_u64/write_u64) and use them to
implement the cpu.rt_runtime_us control file in the CFS cgroup
subsystem.
Signed-off-by: Paul Menage [EMAIL PROTECTED]
--
On Wed, 2008-03-05 at 02:20 -0800, [EMAIL PROTECTED] wrote:
These patches add cgroups read_s64 and write_s64 control file methods
(the signed equivalent of read_u64/write_u64) and use them to
implement the cpu.rt_runtime_us control file in the CFS cgroup
subsystem.
Signed-off-by: Paul
On Tue, Mar 04, 2008 at 10:15:20PM -0800, Paul Menage wrote:
Hi Dhaval,
On Tue, Mar 4, 2008 at 7:23 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
Hi,
We have been working on a library for control groups which would provide
simple APIs for programmers to utilize from userspace and make
Denis V. Lunev wrote:
On Tue, 2008-03-04 at 22:15 -0800, Paul Menage wrote:
Hi Dhaval,
On Tue, Mar 4, 2008 at 7:23 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
Hi,
We have been working on a library for control groups which would provide
simple APIs for programmers to utilize from userspace
On Wed, Mar 5, 2008 at 3:07 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
OK. Hmm, I've not really thought about it. At first thought, it should
not be very difficult. Only thing I am not sure is the arbitrary
grouping of the groups (ok, a bit confusing).
I suspect that the main form of
Hi Dhaval,
Dhaval Giani ??:
I was wonder if creating such library makes any sense at all, considering
the nature of cgroups, the way they work and their possible application?
It seems to me that any attempt to create a 'simple' API would actualy
result in something that will be much
On Tue, Mar 4, 2008 at 7:23 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
libcg will be written mainly in C with lex and yacc for parsing the
configuration
files.
One suggestion - for configuration management tools like this I'd opt
for C++ or Python over C, in order to be able to use STL (or
Paul Menage wrote:
On Tue, Mar 4, 2008 at 7:23 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
libcg will be written mainly in C with lex and yacc for parsing the
configuration
files.
One suggestion - for configuration management tools like this I'd opt
for C++ or Python over C, in order to
Benjamin Thery wrote:
Benjamin Thery wrote:
On Mon, Mar 3, 2008 at 3:55 PM, Pavel Emelyanov [EMAIL PROTECTED] wrote:
Benjamin Thery wrote:
Daniel Lezcano wrote:
Hi,
Some performance tests was made by Benjamin to watch out the impact of
the network namespace. The good news is
Hugh Dickins wrote:
On Wed, 5 Mar 2008, Pavel Emelyanov wrote:
Daisuke Nishimura wrote:
Todo:
- rebase new kernel, and split into some patches.
- Merge with memory subsystem (if it would be better), or
remove dependency on CONFIG_CGROUP_MEM_CONT if possible
(needs to make
Paul Menage wrote:
On Wed, Mar 5, 2008 at 3:07 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
OK. Hmm, I've not really thought about it. At first thought, it should
not be very difficult. Only thing I am not sure is the arbitrary
grouping of the groups (ok, a bit confusing).
I suspect that
On Wed, 5 Mar 2008, Pavel Emelyanov wrote:
Daisuke Nishimura wrote:
Todo:
- rebase new kernel, and split into some patches.
- Merge with memory subsystem (if it would be better), or
remove dependency on CONFIG_CGROUP_MEM_CONT if possible
(needs to make page_cgroup more
On Wed, Mar 05, 2008 at 01:56:23PM +0200, Xpl++ wrote:
Hi Dhaval,
Dhaval Giani ??:
I was wonder if creating such library makes any sense at all, considering
the nature of cgroups, the way they work and their possible application?
It seems to me that any attempt to create a 'simple' API
On Wed, Mar 5, 2008 at 6:24 AM, Balbir Singh [EMAIL PROTECTED] wrote:
Paul Menage wrote:
On Wed, Mar 5, 2008 at 3:07 AM, Dhaval Giani [EMAIL PROTECTED] wrote:
OK. Hmm, I've not really thought about it. At first thought, it should
not be very difficult. Only thing I am not sure is the
Hi Dhaval,
Dhaval Giani ??:
Imagine having a shared/joint household savings account with your wife, and
taking money from it without your wife knowing and vice versa .. then at
some point when you thought that you have some $5K to buy the new super
duper laptop you dreamt about your
Hi,
#ifdef CONFIG_CGROUP_MEM_CONT
+/*
+ * A page_cgroup page is associated with every page descriptor. The
+ * page_cgroup helps us identify information about the cgroup
+ */
+struct page_cgroup {
+ struct list_head lru; /* per cgroup LRU list */
+ struct page
We want to be able to use the memory controller in the following way,
and I'd like to know how practical this is currently, and will be in
the future.
Users are poor at determining how much memory their jobs will actually
use (partly due to poor estimation, partly due to high variance of
memory
On Wed, 05 Mar 2008 17:14:12 +0300
Pavel Emelyanov [EMAIL PROTECTED] wrote:
Strongly agree. Nobody's interested in swap as such: it's just
secondary memory, where RAM is primary memory. People want to
control memory as the sum of the two; and I expect they may also
want to control
On Wed, 5 Mar 2008 16:17:13 -0800
Paul Menage [EMAIL PROTECTED] wrote:
Users are poor at determining how much memory their jobs will actually
use (partly due to poor estimation, partly due to high variance of
memory usage on some jobs). So, we want to overcommit machines, i.e.
we want the
On Wed, Mar 5, 2008 at 5:01 PM, KAMEZAWA Hiroyuki
[EMAIL PROTECTED] wrote:
But to make this more interesting, there are plenty of jobs that will
happily fill as much pagecache as they have available. Even a job
that's just writing out logs will continually expand its pagecache
usage
On Wed, 5 Mar 2008 18:54:52 -0800
Paul Menage [EMAIL PROTECTED] wrote:
On Wed, Mar 5, 2008 at 5:01 PM, KAMEZAWA Hiroyuki
[EMAIL PROTECTED] wrote:
But to make this more interesting, there are plenty of jobs that will
happily fill as much pagecache as they have available. Even a job
22 matches
Mail list logo
