[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.076 / U:3.112 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site