On Thu, 7 Dec 2017 19:51:03 +0000 Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Dec 07, 2017 at 06:03:14PM +0100, Lucas Stach 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 250ms 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. > > > > 250ms to free 2048 entries? That seems excessive but I guess the > embedded ARM system is not that fast. I wonder how common such lenghty lists are. If "significantly" then there may be additional benefit in rearranging free_hot_cold_page_list() so it only walks a small number of list entries at a time. So the data from the first loop is still in cache during execution of the second loop. And that way this long-irq-off-time problem gets fixed automagically. -- 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>
