[lkml]   [2004]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Fw: [RFC] Strange code in cpu_idle()
    The original intent to go with synchronize_kernel and RCU
    protection was for simplicity's sake, as the alternative implementations
    at the time looked like major overkill. Now in defense of this method,
    when entering the idle thread and placing the processor in a holding state
    (hlt) and an RCU grace period is begun, the processor in the holding state
    will be unaware of the new RCU grace period until it exits the idle loop
    callback (pm_idle) anyway, so the rcu_read will block the other processors
    from making RCU grace period completion as much as the processor holding
    state. This is true of all current pm_idle callbacks on i386, x86_64 and
    ia64 with the exception of APM (but i'll conveniently ignore that for now
    ;). When we do take an interrupt to exit the processor holding state and
    run through rcu_check_callbacks we will notice that we are in a hard
    interrupt and will defer marking of the processsor as quiescent. By that
    point we will have exited the idle thread callback therefore making it
    safe to use synchronize_kernel to protect removal of the callback.

    Zwane "who usually doesn't condone interface abuse" Mwaikambo
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:08    [W:0.018 / U:45.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site