On Fri, Aug 12, 2011 at 07:52:06PM +0200, Johannes Weiner wrote:
> On Fri, Aug 12, 2011 at 07:08:23PM +0200, Andrea Arcangeli wrote:
> > 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?
>
> Do we even need to make this fixed? It can be unsigned long long for
> now, but I could imagine leaving it up to the user depending how much
> space she is able/willing to invest to save time:
>
> void synchronize_rcu_with(unsigned long time, unsigned int bits)
> {
> if (generation_counter & ((1 << bits) - 1) == time)
> synchronize_rcu();
> }
This is indeed more convenient for this particular use case, but suppose
that the caller instead wanted to use call_rcu()? The API I am currently
proposing allows either synchronize_rcu() or call_rcu() to be used. In
addition, it allows alternative algorithms, for example:
rcu_get_gp_cookie(&wherever);
...
if (rcu_cookie_gp_elapsed(&wherever))
p = old_pointer; /* now safe to re-use. */
else
p = kmalloc( ... ); /* can't re-use, so get new memory. */
> If you have only 3 bits to store the time, you will synchronize
> falsely to every 8th phase. Better than nothing, right?
;-)
> > 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 don't see how. Even with one bit for the time stamp you get every
> second generation right :-)
I probably need at least two or three bits to account for grace-period
slew, at least if we want to avoid grabbing a global lock each time
one of these APIs is invoked.
> > I think rcu_generation_t is more appropriate because it's not time but
> > a generation/sequence counter.
>
> I intentionally chose a vague name as the unit should be irrelevant to
> the outside world. But I don't feel strongly about this.
Yep, different RCU implementations will need different data in the
rcu_generation_t.
Thanx, Paul
--
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>