Re: [linux-pm] [PATCH 0/5] Container Freezer v6: Reuse SuspendFreezer

[Andrew Morton]

On Tue, 12 Aug 2008 20:47:10 -0700 (Pacific Daylight Time) Vivek Kashyap <kashyapv@xxxxxxxxxx> wrote:

> On Tue, 12 Aug 2008, Andrew Morton wrote:
> 
> > On Mon, 11 Aug 2008 16:53:23 -0700
> > Matt Helsley <matthltc@xxxxxxxxxx> wrote:
> >
> >> This patch series introduces a cgroup subsystem that utilizes the swsusp
> >> freezer to freeze a group of tasks. It's immediately useful for batch job
> >> management scripts. It should also be useful in the future for implementing
> >> container checkpoint/restart.
> >
> > I don't think that this provides anything like sufficient detail to justify
> > merging a whole bunch of stuff into Linux.
> >
> > What does "It's immediately useful for batch job management scripts."
> > mean?  How is it useful?  Examples?  Why would an operator want this
> > feature, and how would it be used?  _much_ more information is needed!
> 
> A batch-manager/job scheduler (such as loadleveler)

what's that?

> must at times stop all 
> tasks associated with a workload being run in a container.

why?

I'm being deliberately obtuse here, but I'm afraid you guys haven't
come anywhere into the vague nearby neighbourhood of adequately describing
this feature.

Please provide proper and full reasons for merging this code into
Linux.  If they exist.  This shouldn't be too hard.

Please put yourself in my position:

me: [patch] <this stuff>
Linus: why are you sending me this?
me: I have not the faintest idea

trust me - many others will be in my position too.

> The workload may 
> constitute of multiple tasks - some of which are in different sessions. 
> A signal (STOP/CONT) to the Containers 'init' wont be transmitted to all 
> the tasks in the Container. The 'freezer' mechanism allows this control
> to be implemented in a clean way.

So why not implement a send-signal-to-all-tasks-in-a-container
controller?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/