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    [W:0.025 / U:61.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site