On Fri, Aug 12, 2011 at 06:57:49PM +0200, Johannes Weiner wrote: > I understand you want to be careful with the promises you make in the > API. How about not even exposing the check for whether a grace period > elapsed, but instead provide a specialized synchronize_rcu()? > > Something like > > void synchronize_rcu_with(rcu_time_t time) > > that only promises all readers from the specified time are finished. > > [ And synchronize_rcu() would be equivalent to > synchronize_rcu_with(rcu_current_time()) if I am not mistaken. ] > > Then you wouldn't need to worry about how the return value of > rcu_cookie_gp_elapsed() might be interpreted, could freely implement > it equal to synchronize_rcu() on TINY_RCU, the false positives with > small cookies would not be about correctness but merely performance. > > And it should still be all that which the THP case requires. > > Would that work? rcu_time_t would still be an unsigned long long like I suggested? About the false positives thing, I failed to see how it's ever possible to return only false positives and never false negatives when cookie and internal counter are not of the same size (and cookie has no enough bits to ever tell if it overflowed or not). I think rcu_generation_t is more appropriate because it's not time but a generation/sequence counter. The ideally the comparison check would be just an inline function reading 2 longs in reverse order in 32bit and comparing it with the stable value we have in page[1]->something_low and page[1]->something_high , so skipping an external call sounds better to me, but the above should also work. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>