On Wed, May 22, 2024 at 4:38 PM Brendan Jackman <jackmanb@xxxxxxxxxx> wrote: > > Hi Lance, thanks for taking a look. > > On Wed, May 22, 2024 at 12:25:30PM +0800, Lance Yang wrote: > > Hi Brendan, > > > > On Tue, May 21, 2024 at 8:57 PM Brendan Jackman <jackmanb@xxxxxxxxxx> wrote: > > > @@ -1077,7 +1081,7 @@ void adjust_present_page_count(struct page *page, struct memory_group *group, > > > */ > > > if (early_section(__pfn_to_section(page_to_pfn(page)))) > > > zone->present_early_pages += nr_pages; > > > - zone->present_pages += nr_pages; > > > + WRITE_ONCE(zone->present_pages, zone->present_pages + nr_pages); > > > > I'm not sure that using the WRITE_ONCE() wrapper would prevent load tearing > > on 'zone->present_pages', but it's probably just me overthinking it :) > > Hmm.. this isn't for load-tearing, it's for store-tearing. I have a > feeling I might be missing your pont here though, can you elaborate? Sorry, my explanation wasn't clear :( I'm a bit confused about whether 'WRITE_ONCE(zone->present_pages, zone->present_pages + nr_pages);' is equivalent to the following: 1 a = zone->present_pages + nr_pages; 2 WRITE_ONCE(zone->present_pages, a); If so, is there any possibility of load tearing on 'zone->present_pages' in line 1? > > I have just noticed that the original "big bad optimizing compiler" > article[1] only says store-tearing has been observed in the wild when > the value being stored can be split into immediates (i.e. is > constant). But it doesn't really seem wise to rely on that. From what > I can tell from tools/memory-model/Documentation you are really out in > the wild with unmarked accesses. > > [1] https://lwn.net/Articles/793253 Thanks for clarifying! Lance
