On Wed, 2021-11-10 at 19:16 +0000, Luck, Tony wrote: > > > > The consequence of sgx_nr_free_pages not being protected is that > > > > its value may not accurately reflect the actual number of free > > > > pages on the system, impacting the availability of free pages in > > > > support of many flows. The problematic scenario isu when the > > > > > > In non-atomicity is not a problem, when it is not a problem :-) > > This is most definitely a problem. > > start with sgx_nr_free_pages == 100 > > Now have a cpu on node0 allocate a page at the same time as another > cpu on node1 allcoates a page. Each holds the relevent per-node lock, > but that doesn't stop both CPUs from accessing the global together: > > CPU on node0 CPU on node1 > sgx_nr_free_pages--; sgx_nr_free_pages--; > > What is the value of sgx_nr_free_pages now? We want it to be 98, > but it could be 99. > > Rinse, repeat thousands of times. Eventually the value of sgx_nr_free_pages > has not even a close connection to the number of free pages. > > -Tony Yeah, so I figured this (see my follow-up response to Reinette) but such description is lacking from the commit message. /Jarkko
