Re: [patch 08/23] dynticks: prepare the RCU code


* Dipankar Sarma <dipankar@xxxxxxxxxx> wrote:

It is duplicating code. That can be easily fixed, but we need to
figure out what we really want from RCU when we are about to switch
off the ticks. It is hard if you want to finish off all the pending
RCUs and go to nohz state. Can you live with backing out if there are
pending RCUs ?

the thing is that when we go idle we /want/ to process whatever delayed
work there might be - rate limited or not. Do you agree with that
approach? I consider this a performance feature as well: this way we can
utilize otherwise lost idle time. It is not a problem that we dont
'batch' this processing: we are really idle and we've got free cycles to
burn. We could even do an RCU processing loop that immediately breaks
out if need_resched() gets set [by an IRQ or by another CPU].

secondly, i think i saw functionality problems when RCU was not
completed before going idle - for example synchronize_rcu() on another
CPU would hang.

what approach would you suggest to achieve these goals?

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

Relevant Pages