[linux-mm-cc] [PATCH] locking refinement
Nitin Gupta
nitingupta910 at gmail.com
Tue Apr 22 01:31:03 EDT 2008
On Mon, Apr 21, 2008 at 3:26 PM, <nai.xia at gmail.com> wrote:
> hi, Nitin,
>
> I have written a patch trying to improve the locking semantics of compcache.
> This patch is based on the following observation:
>
> 1. TLSF is a fast real time algorithm and the main execution paths of
> compcache_make_request is rather short. So it is beneficial to use spin_lock instead of
> mutex_lock if we are sure a certain patch will never sleep.
>
> 2. The core algorithm of TLSF is atomic, the only reason why tlsf_malloc is not
> is that it may get_mem. While it is smart to let TLSF grow the pool
> automatically, tlsf_malloc may still fail due to contention (after trying
> MAX_RETRY_EXPAND times). This contention can not be directly control by its
> client although the client should be responsible for the contention.
>
> 3. As suggested by Andrew Morton "kmap_atomic() is (much) preferred over
> kmap()". We can use kmap_atomic on the paths which are atomic.
>
>
I haven't yet looked into this patch in all its detail but overall it looks good
as it addresses some of the scalability and performance issues. I intend
to integrate this with kernel patch being worked on.
Thanks,
Nitin
More information about the linux-mm-cc
mailing list