On Thu, Jan 17, 2019 at 06:01:18PM +0100, Vlastimil Babka wrote: > On 1/4/19 1:50 PM, Mel Gorman wrote: > > When scanning for sources or targets, PageCompound is checked for huge > > pages as they can be skipped quickly but it happens relatively late after > > a lot of setup and checking. This patch short-cuts the check to make it > > earlier. It might still change when the lock is acquired but this has > > less overhead overall. The free scanner advances but the migration scanner > > does not. Typically the free scanner encounters more movable blocks that > > change state over the lifetime of the system and also tends to scan more > > aggressively as it's actively filling its portion of the physical address > > space with data. This could change in the future but for the moment, > > this worked better in practice and incurred fewer scan restarts. > > > > The impact on latency and allocation success rates is marginal but the > > free scan rates are reduced by 32% and system CPU usage is reduced by > > 2.6%. The 2-socket results are not materially different. > > Hmm, interesting that adjusting migrate scanner affected free scanner. Oh > well. >
Russian Roulette again. The exact scan rates depend on the system state which are non-deterministic. It's not until very late in the series that they stabilise somewhat. In fact, during the development of the series, I had to reorder patches multiple times when a corner case was dealt with to avoid 1 in every 3-6 runs having crazy insane scan rates. The final ordering was based on *relative* stability. > > Signed-off-by: Mel Gorman <[email protected]> > > Acked-by: Vlastimil Babka <[email protected]> > > Nit below. > Nit fixed. -- Mel Gorman SUSE Labs
