lkml.org 
[lkml]   [2010]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Attempted summary of suspend-blockers LKML thread
Hi!

On Mon, 2 Aug 2010 21:38:12 -0700
Paul Menage <menage@google.com> wrote:

> On Sun, Aug 1, 2010 at 11:53 PM, Florian Mickler <florian@mickler.org> wrote:
> >
> > Thinking about it.. I don't know much about cgroups, but I think a
> > process can only be in one cgroup at a time.
>
> A thread can only be in one cgroup in each hierarchy at one time. You
> can mount multiple cgroups hierarchies, with different resource
> controllers on different hierarchies.
>
> >
> > b) you can't use cgroup for other purposes anymore. I.e. if you want to
> > have 2 groups that each only have half of the memory available, how
> > would you then integrate the cgroup-ignore-for-idle-approach with this?
>
> You could mount the subsystem that provides the "ignore-for-idle"
> support on one hierarchy, and partition the trusted/untrusted
> processes that way, and the memory controller subsystem on a different
> hierarchy, with whatever split you wanted for memory controls.
>
> Paul

Thank you for the clarification. That renders my original objections
more or less void.

I've still got some doubts about the flexibility of this approach (think
an open system with arbitrary software components). But with a userspace
manager that sorts processes into the groups this may be a possible
solution.

But we should probably concentrate first on the requirements now. If we
have a set of requirements everyone can agree too, we may be on our way
to get a solution.

Cheers,
Flo


\
 
 \ /
  Last update: 2010-08-03 13:27    [W:0.495 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site