Re: Eventhandlers for CPU state changes

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 12/17/04

  • Next message: Max Laier: "Re: sysctl locking" 
    To: freebsd-arch@FreeBSD.org, Joseph Koshy <joseph.koshy@gmail.com>
Date: Fri, 17 Dec 2004 11:17:16 -0500

    On Friday 17 December 2004 01:28 am, Joseph Koshy wrote:
    > We currently allow CPUs to be enabled and disabled via the
    > sysctl "machdep.hlt_cpus". CPU enabling and disabling can
    > happen at any time in our current design.
    >
    > It would be useful to have an eventhandler hook so that kernel
    > modules can get notified when a CPU is enabled or disabled.
    > For example, schedulers, memory allocators and drivers that
    > use MSRs inside the CPU could use this information.
    >
    > Here is a straightforward attempt at implementing such an
    > eventhandler:
    > http://perforce.freebsd.org/changeView.cgi?CH=67118
    >
    > The question however, is about the right kind of semantics for
    > such an eventhandler (The eventhandler above is at best
    > "advisory" in nature).
    >
    > When we notify a module that "CPU X is going to go away", we
    > may still want to allow that module to run on that CPU to cleanup
    > some state (e.g., disable some MSRs). However we may also wish
    > to prevent other kernel threads from getting scheduled onto the
    > to-be-disabled CPU inadvertently.
    >
    > One way of getting around this problem is for schedulers to register
    > two eventhandlers. The first with priority EVENTHANDLER_PRI_FIRST
    > marks CPU X as about to be disabled. Threads will not then get scheduled
    > onto CPU X unless bound to it. The second with priority
    > EVENTHANDLER_PRI_LAST will actually disable CPU X.
    >
    > Suggestions? Comments?

    I think this is a good first step to getting ULE to work with the hlt_cpus
    stuff. 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Max Laier: "Re: sysctl locking"

    Relevant Pages

    • Re: Nice 19 process still gets some CPU
      ... > Given how much I've read here about schedulers, ... To experiment with these settings you can use two CPU ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Nice 19 process still gets some CPU
      ... | Given how much I've read here about schedulers, ... | kernel compile, etc.) get 100% CPU. ... Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [ANNOUNCE][RFC] plugsched-2.0 patches ...
      ... >> having a clean framework that lets developers in a clean way plug in new ... >> schedulers is quite useful. ... The CPU scheduler must be ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
      ... it allow a per CPU selection of schedulers. ... IO schedulers are alot less performance sensitive than CPU schedulers. ... My guess is that Peter Williams ... fairness isn't always best as humans aren't very altruistic and we need to give unfair preference to interactive tasks in order to stop the users flinging their PCs out the window. ...
      (Linux-Kernel)
    • Eventhandlers for CPU state changes
      ... CPU enabling and disabling can ... It would be useful to have an eventhandler hook so that kernel ... modules can get notified when a CPU is enabled or disabled. ... One way of getting around this problem is for schedulers to register ...
      (freebsd-arch)
    • Quantcast