Eventhandlers for CPU state changes

From: Joseph Koshy (joseph.koshy_at_gmail.com)
Date: 12/17/04

  • Next message: Suleiman Souhlal: "Re: sysctl locking" 
    Date: Fri, 17 Dec 2004 11:58:46 +0530
To: freebsd-arch@freebsd.org

    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?
    _______________________________________________
    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: Suleiman Souhlal: "Re: sysctl locking"

    Relevant Pages