lkml.org 
[lkml]   [2005]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
On Mon, 18 Apr 2005, Paul Jackson wrote:

> Hmmm ... interesting patch. My reaction to the changes in
> kernel/cpuset.c are complicated:
>
> * I'm supposed to be on vacation the rest of this month,
> so trying (entirely unsuccessfully so far) not to think
> about this.
> * This is perhaps the first non-trivial cpuset patch to come
> in the last many months from someone other than Simon or
> myself - welcome.
I'm glad to see this happening.

> This leads to a possible interface. For each of cpus and
> memory, add four per-cpuset control files. Let me take the
> cpu case first.
>
> Add the per-cpuset control files:
> * domain_cpu_current # readonly boolean
> * domain_cpu_pending # read/write boolean
> * domain_cpu_rebuild # write only trigger
> * domain_cpu_error # read only - last error msg

> 4) If the write failed, read the domain_cpu_error file
> for an explanation.


> Otherwise the write will fail, and an error message explaining
> the problem made available in domain_cpu_error for subsequent
> reading. Just setting errno would be insufficient in this
> case, as the possible reasons for error are too complex to be
> adequately described that way.

I guess we hit a limit of the filesystem-interface approach here.
Are the possible failure reasons really that complex ?

Is such an error reporting scheme already in use in the kernel ?
I find the two-files approach a bit disturbing -- we have no guarantee
that the error we read is the error we produced. If this is only to get a
hint, OK.

On the other hand, there's also no guarantee that what we are triggering
by writing in domain_cpu_rebuild is what we have set up by writing in
domain_cpu_pending. User applications will need a bit of self-discipline.

> The above scheme should significantly reduce the number of
> special cases in the update_sched_domains() routine (which I
> would rename to update_cpu_domains, alongside another one to be
> provided later, update_mem_domains.) These new update routines
> will verify that all the preconditions are met, tear down all
> the cpu or mem domains within the scope of the specified cpuset,
> and rebuild them according to the partition defined by the
> pending_*_domain flags on the descendent cpusets. It's the
> same complete rebuild of the partitioning of some subtree,
> each time, without all the special cases for incrementally
> adding and removing cpus or mems from this or that. Complex
> nested if-else-if-else logic is a breeding ground for bugs --
> good riddance.
Oh yes.
There's already a good bunch of if-then-else logic in the cpusets because
of the different flags that can apply. We don't need more.

> There -- what do you think of this alternative?
Most of all, that you write mails faster than I am able to read them, so I
might have missed something. But so far I like your proposal.

Simon.

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

\
 
 \ /
  Last update: 2005-04-19 10:16    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site