maybe dumb question about RCU
Jeff.Haran at citrix.com
Thu Apr 9 20:15:19 EDT 2015
>From: Mandeep Sandhu [mailto:mandeepsandhu.chd at gmail.com]
>Sent: Thursday, April 09, 2015 5:01 PM
>To: Jeff Haran
>Subject: Re: maybe dumb question about RCU
>Indeed the 2 rcu_deref's are giving different pointer values on my machine too (which is running a much newer kernel compared to the one you used in the example, 2.6.32 vs 3.16 on x86_64).
Glad somebody ran it on something newer than the Redhat EL 6.4 that I use and saw the same results. Thanks, it confirms to me that this is intended behavior.
>Here's the result from my machine:
>[545078.854213] rcutest initialized
>[545094.859095] rcu_reader_thread a = 0xffffffffc0ae22b9 b =
>0xffffffffc0ae22b8 off_count = 1 count = 4 [545110.866479] rcu_reader_thread a = 0xffffffffc0ae22b8 b =
>0xffffffffc0ae22b9 off_count = 2 count = 8 [545126.873861] rcu_reader_thread a = 0xffffffffc0ae22b9 b =
>0xffffffffc0ae22b8 off_count = 3 count = 12 [545138.879398] rcu_reader_thread a = 0xffffffffc0ae22b8 b =
>0xffffffffc0ae22b9 off_count = 4 count = 15
>I think this warrants updating the docs, to make this point more distinct?
I would seem to be a good idea to me. This quote from whatisRCU.txt in the Documentation/RCU directory really through me off:
256 If you are going to be fetching multiple fields from the
257 RCU-protected structure, using the local variable is of
258 course preferred. Repeated rcu_dereference() calls look
259 ugly and incur unnecessary overhead on Alpha CPUs.
"look ugly and incur unnecessary overhead on Alpha CPUs" is a long way from "can return different pointer values", which is what it should say.
I guess the question would be where to put it. I note there is a rcu_dereference.txt file in the same directory. It talks about various ways gcc can mess you up when using these pointers and ways to avoid that, but I didn't see anything in it that mentions this particular issue.
More information about the Kernelnewbies