ACCESS_ONCE usage inside llist_add_batch function
Arun KS
getarunks at gmail.com
Wed Mar 4 03:34:01 EST 2015
Hi Akturk,
On Sun, Mar 1, 2015 at 1:42 AM, Cihangir Akturk <cakturk at gmail.com> wrote:
> Reading the lib/llist.c file in the kernel sources, I came across
> the llist_add_bach function defined like this;
>
> bool llist_add_batch(struct llist_node *new_first, struct llist_node
> *new_last,
> struct llist_head *head)
> {
> struct llist_node *first;
>
> do {
> new_last->next = first = ACCESS_ONCE(head->first);
> } while (cmpxchg(&head->first, first, new_first) != first);
>
> return !first;
> }
>
> One thing bugging my mind is the ACCESS_ONCE macro. Is it really
> needed here ? I mean I would write this function with ACCES_ONCE
> moved outside the loop like as follows;
>
ACCESS_ONCE avoids compiler optimization. A kind of compiler optimization
can be caching a value in a register and reusing it.
Why compiler does this? Its his job to create optimized code for speed by
default.
Now llist is lock less linked list, where multiple consumers and producers
can work simultaneously.
Hence during each iteration of the while loop, you want to access the
current value of head->first.
And if you remove ACCESS_ONCE, compiler can keep a copy of head->list in a
register during first iteration and reuse it from register for the
subsequent iterations.
Thanks,
Arun
>
> bool llist_add_batch(struct llist_node *new_first, struct llist_node
> *new_last,
> struct llist_head *head)
> {
> struct llist_node *first, *old;
>
> old = ACCESS_ONCE(head->first);
> for (;;) {
> first = old;
> new_last->next = old;
> old = cmpxchg(&head->first, first, new_first);
> if (old == first)
> break;
> }
>
> return !first;
> }
>
> I think that it may be faster to just use the return value of cmpxchg.
> But I am not sure about this.
>
> Is my understanding correct ?
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150304/5d78b097/attachment.html
More information about the Kernelnewbies
mailing list