On Tue, Feb 07, 2017 at 04:34:59PM +0100, Michal Hocko wrote: > > But we do not care about the whole cpu hotplug code. The only part we > > really do care about is the race inside drain_pages_zone and that will > > run in an atomic context on the specific CPU. > > > > You are absolutely right that using the mutex is safe as well but the > > hotplug path is already littered with locks and adding one more to the > > picture doesn't sound great to me. So I would really like to not use a > > lock if that is possible and safe (with a big fat comment of course). > > And with the full changelog. I hope I haven't missed anything this time. > --- > From 8c6af3116520251cc4ec2213f0a4ed2544bb4365 Mon Sep 17 00:00:00 2001 > From: Michal Hocko <mhocko@xxxxxxxx> > Date: Tue, 7 Feb 2017 16:08:35 +0100 > Subject: [PATCH] mm, page_alloc: do not depend on cpu hotplug locks inside the > allocator > > <SNIP> > > Reported-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > Signed-off-by: Michal Hocko <mhocko@xxxxxxxx> Not that I can think of. It's almost identical to the diff I posted with the exception of the mutex in the cpu hotplug teardown path. I agree that in the current implementation that it should be unnecessary even if I thought it would be more robust against any other hotplug churn. Acked-by: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> -- 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>
