On Fri, Dec 08, 2017 at 01:49:37PM -0800, Andrew Morton wrote: > On Fri, 8 Dec 2017 12:42:17 +0100 Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > > > Since 9cca35d42eb6 (mm, page_alloc: enable/disable IRQs once when freeing > > a list of pages) we see excessive IRQ disabled times of up to 25ms on an > > embedded ARM system (tracing overhead included). > > > > This is due to graphics buffers being freed back to the system via > > release_pages(). Graphics buffers can be huge, so it's not hard to hit > > cases where the list of pages to free has 2048 entries. Disabling IRQs > > while freeing all those pages is clearly not a good idea. > > > > Introduce a batch limit, which allows IRQ servicing once every few pages. > > The batch count is the same as used in other parts of the MM subsystem > > when dealing with IRQ disabled regions. > > > > Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx> > > Suggested-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > --- > > v2: Try to keep the working set of pages used in the second loop cache > > hot by going through both loops in swathes of SWAP_CLUSTER_MAX > > entries, as suggested by Andrew Morton. > > > > To avoid the need to replicate the batch counting in both loops > > I introduced a local batched_free_list where pages to be freed > > in the critical section are collected. IMO this makes the code > > easier to follow. > > Thanks. Is anyone motivated enough to determine whether this is > worthwhile? > I didn't try and I'm not sure I'll get time before dropping offline for holidays but I would expect the benefit to be marginal and only detected through close examination of cache miss stats. We're talking about the cache hotness of a few struct pages for one set of operations before the pages are back on the per-cpu lists. For any large release_pages operation, they are likely to be pushed off the per-cpu lists and onto the buddy lists where the cache data will be thrashed in the near future. It's a nice micro-optimisation but I expect it to be lost in the noise of a release_pages operation. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
