[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6599ad830703080240o6f67df6cvab314c0cb4a3b5ff@mail.gmail.com>
Date: Thu, 8 Mar 2007 02:40:30 -0800
From: "Paul Menage" <menage@...gle.com>
To: vatsa@...ibm.com
Cc: sekharan@...ibm.com, ckrm-tech@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, xemul@...ru, rohitseth@...gle.com,
pj@....com, ebiederm@...ssion.com, mbligh@...gle.com,
winget@...gle.com, containers@...ts.osdl.org, serue@...ibm.com,
dev@...ru, devel@...nvz.org
Subject: Re: [ckrm-tech] [PATCH 1/7] containers (V7): Generic container system abstracted from cpusets code
On 3/8/07, Srivatsa Vaddagiri <vatsa@...ibm.com> wrote:
> On Wed, Mar 07, 2007 at 12:50:03PM -0800, Paul Menage wrote:
> > The callback mutex (which is what container_lock() actually locks) is
> > also used to synchronize fork/exit against subsystem additions, in the
> > event that some subsystem has registered fork or exit callbacks. We
> > could probably have a separate subsystem_mutex for that instead.
>
> Why can't manage_mutex itself be used there (to serialize fork/exit callbacks
> against modification to hierarchy)?
Because manage_mutex can be held for very long periods of time. I
think that a combination of a new lock that's only taken by fork/exit
and register_subsys, plus task_lock (which prevents the current task
from being moved) would be more lightweight.
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists