Hi, Yamamoto-san.
I'm reviewing and testing your patch now.
I think your implementation is better because:
- the group to be charged is determined correctly
at the point of swapout, without fixing the behavior
of move_task of memcg.
(I think the behavior of move_task of memcg should be
When boot with 'cgroup_disable=cpuacct', it turns out subsystem
'cpu' is disabled.
When Balbir posted the patch to add cgroup boot option support,
Paul M noticed this problem, but the patch was accepted without
fixing it.
Signed-off-by: Li Zefan [EMAIL PROTECTED]
---
kernel/cgroup.c | 15
On Mon, Mar 17, 2008 at 4:24 PM, Li Zefan [EMAIL PROTECTED] wrote:
When boot with 'cgroup_disable=cpuacct', it turns out subsystem
'cpu' is disabled.
When Balbir posted the patch to add cgroup boot option support,
Paul M noticed this problem, but the patch was accepted without
fixing it.
- anonymous objects (shmem) are not accounted.
IMHO, shmem should be accounted.
I agree it's difficult in your implementation,
but are you going to support it?
it should be trivial to track how much swap an anonymous object is using.
i'm not sure how it should be associated with cgroups,
Quoting Casey Schaufler ([EMAIL PROTECTED]):
--- Stephen Smalley [EMAIL PROTECTED] wrote:
...
I completely disagree. We have two separate frameworks in the kernel,
one to enforce generic additional security stuff, and one to track
tasks. When I need a feature which tracks
Quoting Oren Laadan ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
Nadia Derbey wrote:
Oren Laadan wrote:
Nadia Derbey wrote:
Oren Laadan wrote:
[EMAIL PROTECTED] wrote:
A couple of weeks ago, a discussion has started after Pierre's
proposal
On Mon, 2008-03-17 at 09:16 -0700, Casey Schaufler wrote:
--- Serge E. Hallyn [EMAIL PROTECTED] wrote:
Quoting Casey Schaufler ([EMAIL PROTECTED]):
...
In particular, capabilities are not an access control mechanism,
they are a privilege mechanism. A lot of discussion about LSM has
On Fri, 2008-03-14 at 15:44 -0700, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
...
I completely disagree. We have two separate frameworks in the kernel,
one to enforce generic additional security stuff, and one to track
tasks. When I need a feature
Implement a cgroup to track and enforce open and mknod restrictions on device
files. A device cgroup associates a device access whitelist with each
cgroup. A whitelist entry has 4 fields. 'type' is a (all), c (char), or
b (block). 'all' means it applies to all types and all major and minor
Serge E. Hallyn wrote:
Implement a cgroup to track and enforce open and mknod restrictions on device
files. A device cgroup associates a device access whitelist with each
cgroup. A whitelist entry has 4 fields. 'type' is a (all), c (char), or
b (block). 'all' means it applies to all types
10 matches
Mail list logo
