From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Hugh Dickins <hugh@veritas.com>
Cc: Pavel Machek <pavel@suse.cz>,
"Randy.Dunlap" <rdunlap@xenotime.net>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
clameter@sgi.com, ntl@pobox.com, akpm@osdl.org,
linux-kernel@vger.kernel.org, ashok.raj@intel.com, ak@suse.de,
mingo@elte.hu
Subject: Re: [PATCH] stop on cpu lost
Date: Fri, 23 Jun 2006 05:57:16 +1000 [thread overview]
Message-ID: <449AF61C.9040807@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0606222030290.23611@blonde.wat.veritas.com>
Hugh Dickins wrote:
> On Fri, 23 Jun 2006, Nick Piggin wrote:
>
>>Hugh Dickins wrote:
>>
>>>I'd expect tasks bound to the unplugged cpu simply not to be run
>>>until "that" cpu is plugged back in.
>>
>>Yes, I don't see why swsusp tasks would need to be migrated and
>>run. OTOH, this would require more swsusp special casing, but
>>apparently that's encouraged ;)
>
>
> No, I wasn't meaning any swsusp special casing at all.
>
> I was just using Pavel's swsusp-related mail as the hook to raise
> the point that had been haunting me with every earlier mail on
> this subject, mails I'd already deleted.
>
> Pavel seemed to imply overriding the requested affinity for tasks
> (in preferring #1 migration), I doubted he really wanted that.
No, but it is currently the only way to do it.
What I had thought you meant was to disallow cpu unplugging,
except with the special case to allow it from swsusp when
suspending the system.
>
>
>>>With proviso that it should be possible to "kill -9" such a task
>>>i.e. it be allowed to run in kernel on a wrong cpu just to exit.
>>>
>>>Presumably this is difficult, because unplugging a cpu will also
>>>remove infrastructure which would, for example, allow "ps" to show
>>>such tasks. Perhaps such infrastructure should remain so long as
>>>there are tasks there.
>>
>>They'll be in the global tasklist, so there should be no reason why
>>they couldn't be migrated over to an online CPU with taskset. Shouldn't
>>require any rewrites, IIRC.
>
>
> I was afraid that "for_each_online_cpu"-type scans would skip over
> the unplugged cpus, in such a way that the homeless tasks might be
> awkwardly invisible in some contexts. If no such problem, fine.
The management stuff tends to go via the pid hashes or the global
tasklist rather than the runqueues. But you might be right that
there would be some corner cases.
>
>
>>But after swsusp comes back up, it will be bringing up the same number
>>of CPUs as went down, won't it? So you shouldn't get into that
>>situation where you'd need to kill stuff, should you?
>
>
> I wasn't meaning "kill -9" for the swsusp case, but for the general
> unplug cpu case. We have a number of homeless tasks, which the admin
> might want to run again when "the" cpu is plugged back in; or might
> want to kill off without having to plug a cpu back in.
Possible maybe... I presumed that would lead to a nightmare of
resource deadlocks (think mutexes). I'd hoped it could still
be useful for the swsusp case where everything gets turned off
at once, though. But I could be wrong...
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-06-22 19:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 3:51 [PATCH] stop on cpu lost KAMEZAWA Hiroyuki
2006-06-22 5:56 ` Andrew Morton
2006-06-22 6:14 ` Christoph Lameter
2006-06-22 15:08 ` Nathan Lynch
2006-06-22 15:45 ` Randy.Dunlap
2006-06-22 15:45 ` Christoph Lameter
2006-06-22 16:05 ` KAMEZAWA Hiroyuki
2006-06-22 16:14 ` Christoph Lameter
2006-06-22 16:24 ` Randy.Dunlap
2006-06-22 17:04 ` Nathan Lynch
2006-06-22 17:20 ` KAMEZAWA Hiroyuki
2006-06-22 18:22 ` Pavel Machek
2006-06-22 18:35 ` Christoph Lameter
2006-06-22 18:37 ` Pavel Machek
2006-06-22 18:54 ` Hugh Dickins
2006-06-22 19:27 ` Nick Piggin
2006-06-22 19:46 ` Hugh Dickins
2006-06-22 19:57 ` Nick Piggin [this message]
2006-06-22 20:25 ` Hugh Dickins
2006-06-22 21:44 ` Pavel Machek
2006-06-22 19:52 ` Jeremy Fitzhardinge
2006-06-22 21:46 ` Pavel Machek
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=449AF61C.9040807@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=ashok.raj@intel.com \
--cc=clameter@sgi.com \
--cc=hugh@veritas.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ntl@pobox.com \
--cc=pavel@suse.cz \
--cc=rdunlap@xenotime.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox