On Thu, May 12, 2022 at 12:43:25PM -0700, Andrew Morton wrote: > On Thu, 12 May 2022 09:50:37 +0100 Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > > > Changelog since v2 > > o More conversions from page->lru to page->[pcp_list|buddy_list] > > o Additional test results in changelogs > > > > Changelog since v1 > > o Fix unsafe RT locking scheme > > o Use spin_trylock on UP PREEMPT_RT > > > > This series has the same intent as Nicolas' series "mm/page_alloc: Remote > > per-cpu lists drain support" -- avoid interference of a high priority > > task due to a workqueue item draining per-cpu page lists. While many > > workloads can tolerate a brief interruption, it may be cause a real-time > > s/may be/may/ > > > task runnning on a NOHZ_FULL CPU to miss a deadline and at minimum, > > s/nnn/nn/ > Correct. > > the draining in non-deterministic. > > s/n/s/;) > Think that one is ok. At least spell check did not complain. > > Currently an IRQ-safe local_lock protects the page allocator per-cpu lists. > > The local_lock on its own prevents migration and the IRQ disabling protects > > from corruption due to an interrupt arriving while a page allocation is > > in progress. The locking is inherently unsafe for remote access unless > > the CPU is hot-removed. > > I don't understand the final sentence here. Which CPU and why does > hot-removing it make the locking safe? > The sentence can be dropped because it adds little and is potentially confusing. The PCP being safe to access remotely is specific to the context of the CPU being hot-removed and there are other special corner cases like zone_pcp_disable that modifies a per-cpu structure remotely but not in a way that causes corruption. -- Mel Gorman SUSE Labs
