On Sun 23-11-14 13:50:50, Tetsuo Handa wrote:
> >From 92aec48e3b2e21c3716654670a24890f34c58683 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> Date: Sun, 23 Nov 2014 13:39:25 +0900
> Subject: [PATCH 2/5] mm: Kill shrinker's global semaphore.
>
> Currently register_shrinker()/unregister_shrinker() calls down_write()
> while shrink_slab() calls down_read_trylock().
> This implies that the OOM killer becomes disabled because
> shrink_slab() pretends "we reclaimed some slab memory" even
> if "no slab memory can be reclaimed" when somebody calls
> register_shrinker()/unregister_shrinker() while one of shrinker
> functions allocates memory and/or holds mutex which may take
> unpredictably long duration to complete.
Which load would be SLAB mostly that this would matter?
Other than that I thought that {un}register_shrinker are really unlikely
paths called during initialization and tear down which usually do not
happen during OOM conditions.
> This patch replaces global semaphore with per a shrinker refcounter
> so that shrink_slab() can respond "we could not reclaim slab memory"
> when out_of_memory() needs to be called.
>
> Before this patch, response time of addition/removal are unpredictable
> when one of shrinkers are in use by shrink_slab(), nearly 0 otherwise.
>
> After this patch, response time of addition is nearly 0. Response time of
> removal remains unpredictable when the shrinker to remove is in use by
> shrink_slab(), nearly two RCU grace periods otherwise.
I cannot judge the patch itself as this is out of my area but is the
complexity worth it? I think the OOM argument is bogus because there
SLAB usually doesn't dominate the memory consumption in my experience.
--
Michal Hocko
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>