On Tue, 31 Mar 2015 18:11:32 -0400 Sasha Levin <sasha.le...@oracle.com> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
