We can think about optimizing this to if (!sb->sprunes) wake_up(&sb->s_wait_prunes);Hardly. This is only the case when two or more shrinkers are active in parallel. If that was the case often, we would have seen this much more frequent IMHO.
But this avoids taking 2nd lock on fast path. Kirill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- From: Jan Blunck <[email protected]>
- Re: [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- From: Kirill Korotaev <[email protected]>
- Re: [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- From: Jan Blunck <[email protected]>
- Re: [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- From: Balbir Singh <[email protected]>
- Re: [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- From: Jan Blunck <[email protected]>
- [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- Prev by Date: Re: [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- Next by Date: Re: [PATCH] libata queue updated
- Previous by thread: Re: [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- Next by thread: Re: [PATCH] shrink_dcache_parent() races against shrink_dcache_memory()
- Index(es):