On 08-01-2008 08:53, Eric Dumazet wrote: > David Miller a écrit : ... >> Furthermore, these: >> >> rcu_read_unlock_bh() >> rcu_read_lock_bh() >> >> sequences are at best funny looking. For other lock types we would >> look at this and ask "Does this even accomplish anything reliably?" > > Well, original code exactly does the same thing. > >> >> The answer here is that it wants the preempt_enable() to run to get >> any potential kernel preemptions executed. It also allows any >> pending software interrupts to run. >> >> So this does something reliably only because rcu_read_unlock_bh() has >> specific and explicit side effects. >> > > I will post a patch to introduce a helper function, so that this is > clearly documented and not relying on side effects. Actual > implementation has latency > problems on empty hash tables if CONFIG_PREEMPT=n > > >> I don't know, to me it just looks awful :-) I better understood the >> original code.
It seems this patch only made it more visible how it currently works. I don't know what changes do you plan for this helper function, but my proposal is to add some counter and break this rcu only after looping for some time. Alternatively cpu_relax() could be probably used between these "locks". Without this probably some cache problems are possible, but you know this better, I guess. Regards, Jarek P. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
