[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