Re: [RFC PATCH 0/3] page count lock for simpler put_page

[Michel Lespinasse <walken@google.com>]

On Fri, Aug 12, 2011 at 9:08 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Fri, Aug 12, 2011 at 05:36:16PM +0200, Andrea Arcangeli wrote:
>> On Tue, Aug 09, 2011 at 04:04:21AM -0700, Michel Lespinasse wrote:
>> > - It'd be sweet if one could somehow record the time a THP page was
>> > created, and wait for at least one RCU grace period *starting from the
>> > recorded THP creation time* before splitting huge pages. In practice,
>> > we would be very unlikely to have to wait since the grace period would
>> > be already expired. However, I don't think RCU currently provides such
>> > a mechanism - Paul, is this something that would seem easy to
>> > implement or not ?
>
> It should not be hard.  I already have an API for rcutorture testing
> use, but it is not appropriate for your use because it is unsynchronized.

Yay!

> We need to be careful with what I give you and how you interpret it.
> The most effective approach would be for me to give you an API that
> filled in a cookie given a pointer to one, then another API that took
> pointers to a pair of cookies and returned saying whether or not a
> grace period had elapsed.  You would do something like the following:
>
>        rcu_get_gp_cookie(&pagep->rcucookie);
>        . . .
>
>        rcu_get_gp_cookie(&autovarcookie);
>        if (!rcu_cookie_gp_elapsed(&pagep->rcucookie, &autovarcookie))
>                synchronize_rcu();

This would work. The minimal interface I actually need would be:

> So, how much space do I get for ->rcucookie?  By default, it is a pair
> of unsigned longs, but I could live with as small as a single byte if
> you didn't mind a high probability of false negatives (me telling you
> to do a grace period despite 16 of them having happened in the meantime
> due to overflow of a 4-bit field in the byte).

Two longs per cookie would work. We could most easily store them in
(page_head+2)->lru. This assumes THP pages will always be at least
order 2, but I don't think that's a problem.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>