Re: How to notify app of changed cpu/mem/io node configuration?

[Rusty Russell <rusty@rustcorp.com.au>]

On Wed, 2004-06-30 at 08:41, Dave Hansen wrote:
> On Mon, 2004-06-28 at 23:24, Greg KH wrote: 
> > On Mon, Jun 28, 2004 at 05:38:08PM -0700, Paul Jackson wrote:
> > > I can imagine using for notification a new signal, that could be sent by
> > > an administrator or system service (batch manager, perhaps) to tasks if
> > > their allowed CPUs or Memory Nodes or other such had changed.
> > 
> > I recall some initial proposals for when CPUs were offlined, to send the
> > applications that were bound to those CPUs a specific signal, but I do
> > not know if that got implemented or not.  Anyone know?
> 
> I don't see anything in the various signal.h files that looks likely.  
> 
> But, we'll probably need some kind of synchronous process notification
> at some point.  If an app gets itself in a bad state such that it has no
> possibility of being scheduled, or gets itself into some other hopeless
> state due to a hotplug action, the kernel will likely have the option to
> kill it.  
> 
> I think the problem for the kernel comes when we consider how to notify
> the app.  Doing a hotplug event and having the scripts send an
> appropriate signal isn't really a viable option because the kernel
> wouldn't really know when each app had a chance to handle the signal. 
> Sleeping for 5 seconds and hoping for the best probably isn't the best
> option, either. :)
> 
> The other option would be to have the kernel send signals to the
> processes, and recheck the "impossible state" after the signal has been
> handled.
> 
> I don't really remember how the discussions about CPU hotplug ended, but
> I wonder if a much more generic signal could be of more use than a
> single task CPU hotplug signal.
> 
> What about a SIGHOTPLUG that can be used whenever the kernel notices
> that a task is using a resource that's being hotplugged?

SIGRECONFIG was suggested.  Default is ignored, and you get unbound from
CPU anyway.  Later on would cover memory changes as well.  But speaking
with another OS which uses this approach, they found that vendors
preferred the "run a script" approach anyway, so the solution is
probably:

	(1) If you want to do this, ask on DBUS for any naks.
	(2) If no NAKs, tell kernel.
	(3) /sbin/hotplug tells DBUS when it's done.

The real killer was that we can't add signals without breaking glibc,
since it never asks the kernel how many signals there are.

Hope that clarifies!
Rusty.

Anyone who quotes me in their signature is an idiot -- Rusty Russell



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel