Re: [PATCH v2] kref: warn on uninitialized kref

[Bart Van Assche]

On 05/17/14 23:14, Mikulas Patocka wrote:
> BTW. if we talk about performance - what about replacing:
> 
> 	if (atomic_dec_and_test(&variable)) {
> 		... release(object);
> 	}
> 
> with this:
> 
> 	if (atomic_read(&variable) == 1 || atomic_dec_and_test(&variable)) {
> 		barrier();
> 		... release(object);
> 	}
> 
> It avoids the heavy atomic instruction if there is just one reference. Is 
> there any problem with this? At least on x86 we could do this always 
> (there is no read reordering in hardware, so barrier() is sufficient to 
> prevent reads from being reordered with atomic_read). On the architectures 
> that reorder reads, we could do it only if the release method doesn't 
> contain any reads of the object being released.

Although I'm not sure how big the performance impact is in this context,
this change has a performance impact if variable > 1. The
atomic_dec_and_test() triggers at most one cache line state transition.
The atomic_read() + atomic_dec_and_test() triggers two cache line state
transitions if "variable" is not in the local cache, namely first from
invalid to shared and then from shared to exclusive. See also section
"11.4 CACHE CONTROL PROTOCOL" and "Table 11-4 MESI Cache Line States" in
the Intel Software Developer Manual, Volume 3 for more information.

Bart.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/