On Tue, 31 Mar 2015 18:11:32 -0400 Sasha Levin <sasha.levin@xxxxxxxxxx> wrote: > Freeing pages became a rather costly operation, specially when multiple debug > options are enabled. This causes hangs when an attempt to free a large amount > of 0-order is made. Two examples are vfree()ing large block of memory, and > punching a hole in a shmem filesystem. > > To avoid that, move any free operations that involve batching pages into a > list to a workqueue handler where they could be freed later. eek. __free_pages() is going to be a hot path for someone - it has 500+ callsites. And this patch might cause problems for rt_prio() tasks which run for a long time, starving out the workqueue thread. And probably other stuff I didn't think of... What whacky debug option is actually causing this? Full-page poisoning? Stick a cond_resched() in __vunmap() ;) -- 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>