Re: [PATCH] stop on cpu lost

[Hugh Dickins]

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.

> > 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.

> 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.

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