In article <[email protected]>, Dennis Ferguson <[email protected]> wrote: >Hello, > >I have a route lookup data structure which is fairly speedy and >which is designed to be modified (i.e. routes added or deleted) >while lookups are concurrently being done. This is part of a >project to produce a fully SMP-capable networking stack. > >Unfortunately, however, I wasn't able to eliminate all ordering >dependencies from the structure; for it to work properly some >writes to the structure must be seen by readers in the order >they were written. This in general requires calling membar_producer() >between the writes that need to be seen in order, and membar_consumer() >between reads which need to see the same order. While calling >membar_producer() in the writer isn't a problem, calling membar_consumer() >in the readers turns out to be a big problem; that's an expensive >function in the cases I've tried, and that expense is paid in the >most heavily used, performance-critical lookup functions. > >The thing about the latter functions, however, is that each read >they do from the structure is dependent on the previous read; what >it reads tells it how to compute what to read next. This is good, >since I found this very nice paper > > http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf > >which has a table and text on page 16 which indicates that the only CPU which >Linux runs on which may reorder dependent loads is the Alpha. Everything >else can run without the read barriers. > >So I now have a macro which calls membar_consumer() if compiled for an >Alpha, but does nothing when compiled for anything else. If there were >a system membar_X() function which did the right thing for this case, however, >it wouldn't need the machine-dependent #ifdef.
Would RCU be helpful in your scenario? christos
