linux-kernel - Re: [PATCH] binder: replace kzalloc with kmem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161122135302.GA10497@kroah.com>
Date:   Tue, 22 Nov 2016 14:53:02 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Ganesh Mahendran <opensource.ganesh@...il.com>
Cc:     arve@...roid.com, riandrews@...roid.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] binder: replace kzalloc with kmem_cache

On Tue, Nov 22, 2016 at 07:17:30PM +0800, Ganesh Mahendran wrote:
> This patch use kmem_cache to allocate/free binder objects.

Why do this?

> It will have better memory efficiency.

Really?  How?  It should be the same, if not a bit worse.  Have you
tested this?  What is the results?

> And we can also get object usage details in /sys/kernel/slab/* for
> futher analysis.

Why do we need this?  Who needs this information and what are you going
to do with it?

> Signed-off-by: Ganesh Mahendran <opensource.ganesh@...il.com>
> ---
>  drivers/android/binder.c | 127 ++++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 104 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 3c71b98..f1f8362 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -54,6 +54,14 @@
>  static HLIST_HEAD(binder_deferred_list);
>  static HLIST_HEAD(binder_dead_nodes);
>  
> +static struct kmem_cache *binder_proc_cachep;
> +static struct kmem_cache *binder_thread_cachep;
> +static struct kmem_cache *binder_node_cachep;
> +static struct kmem_cache *binder_ref_cachep;
> +static struct kmem_cache *binder_transaction_cachep;
> +static struct kmem_cache *binder_work_cachep;
> +static struct kmem_cache *binder_ref_death_cachep;

That's a lot of different caches, are you sure they don't just all get
merged together anyway for most allocators?

Don't create lots of little caches for no good reason, and without any
benchmark numbers, I'd prefer to leave this alone.  You are going to
have to prove this is a win to allow this type of churn.

thanks,

greg k-h