linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: How to notify app of changed cpu/mem/io node configuration?
Date: Tue, 29 Jun 2004 23:15:28 +0000	[thread overview]
Message-ID: <20040629161528.213c6e10.pj@sgi.com> (raw)
In-Reply-To: <20040628173808.04718b83.pj@sgi.com>

Dave wrote:
> But, we'll probably need some kind of synchronous process notification
> at some point. 

Did you mean "some kind of asynchronous ..."?

> If ... app ... hopeless ... the kernel will likely have the option to
> kill it.  

More commonly, it seems that the kernel just forces the app onto some
CPU/Memory that will work, such as the lowest currently online CPU.
Essentially, CPU 0 (and I guess Memory Node 0, in time) become the
orphanage for homeless tasks.

> Sleeping for 5 seconds and hoping for the best probably isn't the best
> option, either. :)

Yeah - the kernel doesn't really want to be playing such games.
Hence actions that might require such should be left to userland.

For example, on orderly moving of apps from one Node to another
could be accomplished by user code that took its time and did what
it had to do to move (or kill) apps off old Node, before it told
the kernel "all clear - remove old Node from service"

> I wonder if a much more generic signal could be of more use ...

That's my inclination as well.  These sorts of events are rare. Send one
generic signal, and let the recipient poke around and figure out what
has changed that it cares about and deal with it.  I could even imagine
overloading SIGPWR for this purpose, if new signal numbers/names are too
difficult to come by.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373


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

  parent reply	other threads:[~2004-06-29 23:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-29  0:38 How to notify app of changed cpu/mem/io node configuration? Paul Jackson
2004-06-29  6:24 ` Greg KH
2004-06-29  8:37 ` Paul Jackson
2004-06-29 22:41 ` Dave Hansen
2004-06-29 23:15 ` Paul Jackson [this message]
2004-06-29 23:39 ` Dave Hansen
2004-06-29 23:53 ` Rusty Russell
2004-06-30  1:22 ` Paul Jackson
2004-06-30  1:38 ` Dave Hansen
2004-06-30  1:40 ` Paul Jackson
2004-06-30  2:16 ` Paul Jackson
2004-06-30 11:57 ` jlm_devel
2004-06-30 12:26 ` Paul Jackson
2004-06-30 13:08 ` Paul Jackson
2004-06-30 17:37 ` jlm_devel

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=20040629161528.213c6e10.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=linux-hotplug@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).