From: Nathan Lynch <ntl@pobox.com>
To: Paul Jackson <pj@sgi.com>
Cc: akpm@osdl.org, anton@samba.org, simon.derr@bull.net,
linux-kernel@vger.kernel.org
Subject: Re: cpusets not cpu hotplug aware
Date: Wed, 23 Aug 2006 18:39:44 -0500 [thread overview]
Message-ID: <20060823233944.GG11309@localdomain> (raw)
In-Reply-To: <20060823153952.066e9a58.pj@sgi.com>
Paul Jackson wrote:
> Nathan wrote:
> > How about this?
>
> The code likely works, and the locking seems ok at first blush.
> And this patch seems to match just what I asked for ;).
>
> But the more I think about this, the less I like this direction.
>
> Your patch, and what I initially asked for, impose a policy and create
> a side affect. When you bring a cpu online, the top cpuset changes as
> a side affect, in order to impose a policy that the top cpuset tracks
> what is online.
>
> The kernel should avoid such side affects and avoid imposing policy.
If you want to call that a policy that's fine, but it hardly seems to
be a non-intuitive behavior to me, especially in the case that the
administrator has not explicitly configured any cpusets.
> It should be user code that imposes the policy that the top cpuset
> tracks what is online.
>
> The kernel gets things going with reasonable basic defaults at system
> boot, then adapts to whatever user space mandates from then on.
>
> Kernels should provide generic, orthogonal mechanisms.
Maybe the cpuset code should just stay out of the way unless the admin
has instantiated one?
> Let user space figure out what it wants to do with them.
The user who initially reported this probably has no idea what cpusets
are or how to deal with the situation.
> It is not a kernel bug that the top cpuset doesn't track what is
> online.
It's a bug that one's ability to bind a task to a new cpu is entirely
dependent on whether you know your way around cpusets. Doesn't sound
orthogonal to me.
Try looking at it this way. You have an application that works on
distro x, where cpu hotplug is supported but cpusets is not enabled in
the kernel config. That application is cpu hotplug-aware, and binding
a task to a new cpu just works. Now, with distro x+1, cpusets is
enabled and that same scenario doesn't work anymore. That's generally
viewed as a regression.
And no, I don't like pushing the responsibility for fixing up the
top-level cpuset out to userspace -- that would force apps to
busy-wait (and for how long?) for the new cpu to be added to the
top-level cpuset by the hotplug helper. It means something as simple
as this:
# echo 1 > /sys/devices/system/cpu/cpu3/online
# taskset 0x8 foo
has a race condition, depending on your kernel's configuration.
next prev parent reply other threads:[~2006-08-23 23:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-21 13:27 cpusets not cpu hotplug aware Anton Blanchard
2006-08-21 13:54 ` Simon Derr
2006-08-21 17:43 ` Paul Jackson
2006-08-21 19:21 ` Anton Blanchard
2006-08-21 20:42 ` [PATCH] cpuset code prevents binding tasks to new cpus Nathan Lynch
2006-08-21 23:04 ` Paul Jackson
2006-08-21 23:27 ` Nathan Lynch
2006-08-22 4:42 ` Paul Jackson
2006-08-22 5:07 ` Andrew Morton
2006-08-21 21:01 ` cpusets not cpu hotplug aware Paul Jackson
2006-08-22 4:51 ` Andrew Morton
2006-08-22 5:04 ` Nathan Lynch
2006-08-22 5:11 ` Andrew Morton
2006-08-22 5:14 ` Paul Jackson
2006-08-23 22:11 ` Nathan Lynch
2006-08-23 22:39 ` Paul Jackson
2006-08-23 23:39 ` Nathan Lynch [this message]
2006-08-24 2:19 ` Paul Jackson
2006-08-23 23:49 ` Nathan Lynch
2006-08-24 0:12 ` Andrew Morton
2006-08-24 0:48 ` [PATCH] cpuset code prevents binding tasks to new cpus Nathan Lynch
2006-08-24 2:54 ` cpusets not cpu hotplug aware Paul Jackson
2006-08-22 5:06 ` Paul Jackson
2006-08-22 5:14 ` Andrew Morton
2006-08-22 5:21 ` Paul Jackson
2006-08-23 14:58 ` Anton Blanchard
2006-08-23 18:59 ` Paul Jackson
2006-08-23 19:08 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060823233944.GG11309@localdomain \
--to=ntl@pobox.com \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=simon.derr@bull.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.