On Thu, Oct 18, 2018 at 12:20:55PM +0100, Mel Gorman wrote: > On Wed, Oct 17, 2018 at 10:23:27PM +0800, Aaron Lu wrote: > > > RT has had problems with cpu_relax in the past but more importantly, as > > > this delay for parallel compactions and allocations of contig ranges, > > > we could be stuck here for very long periods of time with interrupts > > > > The longest possible time is one CPU accessing pcp->batch number cold > > cachelines. Reason: > > When zone_wait_cluster_alloc() is called, we already held zone lock so > > no more allocations are possible. Waiting in_progress to become zero > > means waiting any CPU that increased in_progress to finish processing > > their allocated pages. Since they will at most allocate pcp->batch pages > > and worse case are all these page structres are cache cold, so the > > longest wait time is one CPU accessing pcp->batch number cold cache lines. > > > > I have no idea if this time is too long though. > > > > But compact_zone calls zone_wait_and_disable_cluster_alloc so how is the > disabled time there bound by pcp->batch? My mistake, I misunderstood spin_lock_irqsave() and thought lock would need be acquired before irq is disabled... So yeah, your concern of possible excessive long irq disabled time here is true.
