Re: CPU Hotplug: Hotplug Script And SIGPWR

From: Nick Piggin (piggin_at_cyberone.com.au)
Date: 01/20/04

  • Next message: Rusty Russell: "Re: CPU Hotplug: Hotplug Script And SIGPWR" 
    Date:	Tue, 20 Jan 2004 19:14:12 +1100
To: Tim Hockin <thockin@hockin.org>

    Tim Hockin wrote:

    >On Tue, Jan 20, 2004 at 06:45:37PM +1100, Nick Piggin wrote:
    >
    >>>I guess a hotplug script MAY fail. I don't think it's a good idea to make
    >>>your CPU hotplug script fail. May and Misght are different. It's up to
    >>>the
    >>>implementor whether the script can get into a failure condition.
    >>>
    >>>
    >>Sorry bad wording. The script may fail to be executed.
    >>
    >
    >Under what conditions? Not arbitrary entropy, surely. If a hotplug script
    >is present and does not blow up, it should be safe to assume it will be run
    >upon an event being delivered. If not, we have a WAY bigger problem :)
    >

    That assumption is not safe. The main problems are of course process limits
    and memory allocation failure.

    >
    >>>What if <which> process needs guaranteed scheduling latency? Do we really
    >>>_guarantee_ scheduling latency *anywhere*?
    >>>
    >>We do guarantee that a realtime task won't be blocked waiting for
    >>a hotplug script to fault in and start it up again (which may not
    >>happen). Not sure how important this issue is.
    >>
    >
    >We have a conflict of priority here. If an RT task is affined to CPU A and
    >CPU A gets yanked out, what do we do?
    >
    >Obviously the RT task can't keep running as it was. It was affined to A.
    >Maybe for a good reason. I see we have a few choices here:
    >
    >* re-affine it automatically, thereby silently undoing the explicit
    > affinity.
    >* violate it's RT scheduling by not running it until it has been re-affined
    > or CPU A returns to the pool/
    >
    >Sending it a SIGPWR means you have to run it on a different CPU that it was
    >affined to, which is already a violation.
    >

    At least the task has the option to handle the problem.

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

  • Next message: Rusty Russell: "Re: CPU Hotplug: Hotplug Script And SIGPWR"

    Relevant Pages

    • Re: CPU Hotplug: Hotplug Script And SIGPWR
      ... > That assumption is not safe. ... to run a hotplug script is a BAD THING. ... invent new signals? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: CPU Hotplug: Hotplug Script And SIGPWR
      ... >>I guess a hotplug script MAY fail. ... >>your CPU hotplug script fail. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • CPU Hotplug: Hotplug Script And SIGPWR
      ... > the CPU is completely dead (i.e after issuing the CPU_DEAD ... The original code wanted to block until the hotplug script ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.12-rc2-mm2
      ... As the cpu-mask is set to only this cpu _smp_processor_idis safe. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: ANNOUNCE: User-space System Device Enumation (uSDE)
      ... >> Mainly I'm asking because I did try putting a hotplug script into an ... > does get called during early boot, before init is started up. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)