Messages in this thread | | | From | "Huang, Ying" <> | Subject | Re: Can you help us on memory barrier usage? (was Re: [PATCH v4 4/6] mm: swap: Allow storage of all mTHP orders) | Date | Mon, 25 Mar 2024 11:20:29 +0800 |
| |
Ryan Roberts <ryan.roberts@arm.com> writes:
> On 22/03/2024 02:38, Huang, Ying wrote: >> Hi, Paul, >> >> Can you help us on WRITE_ONCE()/READ_ONCE()/barrier() usage as follows? >> For some example kernel code as follows, >> >> " >> unsigned char x[16]; >> >> void writer(void) >> { >> memset(x, 1, sizeof(x)); >> /* To make memset() take effect ASAP */ >> barrier(); >> } >> >> unsigned char reader(int n) >> { >> return READ_ONCE(x[n]); >> } >> " >> >> where, writer() and reader() may be called on 2 CPUs without any lock. > > For the situation we are discussing, writer() is always called with a spin lock > held. So spin_unlock() will act as the barrier in this case; that's my argument > for not needing the explicit barrier(), anyway. Happy to be told I'm wrong.
Yes. spin_unlock() is a barrier too. There are some operations between writer() and spin_unlock(), so I want to check whether it make any sense to add a barrier earlier.
>> It's acceptable for reader() to read the written value a little later. >> Our questions are, >> >> 1. because it's impossible for accessing "unsigned char" to cause >> tearing. So, WRITE_ONCE()/READ_ONCE()/barrier() isn't necessary for >> correctness, right? >> >> 2. we use barrier() and READ_ONCE() in writer() and reader(), because we >> want to make writing take effect ASAP. Is it a good practice? Or it's >> a micro-optimization that should be avoided?
-- Best Regards, Huang, Ying
| |