Re: [ckrm-tech] Re: [PATCH 1/3] CPUMETER: add cpumeter framework to the CPUSETS

From: Simon Derr <simon.derr@bull.net>
To: KUROSAWA Takahiro <kurosawa@valinux.co.jp>
Cc: Paul Jackson <pj@sgi.com>,
	taka@valinux.co.jp, magnus.damm@gmail.com, dino@in.ibm.com,
	linux-kernel@vger.kernel.org, ckrm-tech@lists.sourceforge.net
Subject: Re: [ckrm-tech] Re: [PATCH 1/3] CPUMETER: add cpumeter framework to the CPUSETS
Date: Fri, 30 Sep 2005 11:39:24 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0509301117500.28042@localhost.localdomain> (raw)
In-Reply-To: <20050929025328.E4BFC70046@sv1.valinux.co.jp>

On Thu, 29 Sep 2005, KUROSAWA Takahiro wrote:

> > Oh I think not.  My primary motivation in pushing on this point
> > of the design was to allow CPUSET 2a and 2b to have a smaller
> > cpumask than CPUSET 1a.  This is used for example to allow a job
> > that is running in 1a to setup two child cpusets, 2a and 2b,
> > to run two subtasks that are constrained to smaller portions of
> > the CPUs allowed to the job in 1a.
>
> Maybe I still misunderstand your idea.
> The guarantee assigned to CPUSET 1a might not be satisfied if
> tasks are attached to CPUSET 2a only and no tasks are attached to
> CPUSET 1a nor CPUSET 2b.  Does your idea leave as it is because
> the user sets up CPUSETs like that?

Hi Takahiro-san

It seems to me that this "guarantee" can only be guaranteed if the owner
of cpuset 1a:
-runs enough tasks to use all the cpus of cpuset 1a
-does not tamper with the scheduler decisions by creating other cpusets
inside cpuset 1a, or by using sched_setaffinity().

Outside of this, he accepts to get less cpu than "guaranteed".
Sounds acceptable to me.

	Simon.