Andrew Morton wrote:
> On Mon, 21 Aug 2006 14:01:48 -0700
> Paul Jackson <[email protected]> wrote:
> > Anton wrote:
> > > If cpuset_cpus_allowed doesnt return the current online mask and we want
> > > to schedule on a cpu that has been added since boot it looks like we
> > > will fail.
> >
> > In general, on systems actually using cpusets, that -is- what should
> > happen. Just because a cpu was brought online doesn't mean it was
> > intended to be allowed in any given tasks current cpuset.
> >
> > Granted, I would guess users of systems not using cpusets (but
> > still have cpusets configured in their kernel, as is common in some
> > distro kernels), would expect the behaviour you expected - bringing
> > a cpu (or memory node) on or offline would make it available (or
> > not) for something like a sched_setaffinity (or mbind/set_mempolicy)
> > immediately, without having to invoke some magic cpuset voodoo.
> >
> > Offhand, this sounds to me like a choice of two modes of operation.
> >
> > If you aren't actually using cpusets (so every task is in the
> > original top_cpuset) then you'd expect that cpuset to "get out
> > of the way", meaning top_cpuset (the only cpuset, in this case)
> > tracked whatever cpus and nodes were online at the moment.
> >
> > If instead you start messing with cpusets (creating more than one
> > of them and moving tasks between them) then you'd expect cpusets
> > to be enforced, without automatically adding newly added cpus or
> > memory nodes to existing cpusets. Only the user knows which
> > cpusets should get the added cpus or memory nodes in this case.
> >
> > I don't jump for joy over yet another modal state flag. But I don't see
> > a better alternative -- do you?
> >
>
> If the kernel provider (ie: distro) has enabled cpusets then it would be
> appropriate that they also provide a hotplug script which detects whether their
> user is actually using cpusets and if not, to take some sensible default action.
> ie: add the newly-added CPU to the system's single cpuset, no?
I think it would be more sensible for the default (i.e. user hasn't
explicitly configured any cpusets) behavior on a CONFIG_CPUSETS=y
kernel to match the behavior with a CONFIG_CPUSETS=n kernel. Right
now we don't have that. Binding a task to a newly added cpu just
fails if CONFIG_CPUSETS=y, but it works if CONFIG_CPUSETS=n.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
