From: Peikan Tsai <peikantsai@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
devel@driverdev.osuosl.org, tkjos@android.com,
linux-kernel@vger.kernel.org, arve@android.com,
Joel Fernandes <joel@joelfernandes.org>,
maco@android.com
Subject: Re: [PATCH] binder: Use kmem_cache for binder_thread
Date: Mon, 2 Sep 2019 22:12:25 +0800 [thread overview]
Message-ID: <20190902141225.GA21112@mark-All-Series> (raw)
In-Reply-To: <20190830063943.GH15257@kroah.com>
On Fri, Aug 30, 2019 at 08:39:43AM +0200, Greg KH wrote:
> On Fri, Aug 30, 2019 at 02:59:01AM +0800, Peikan Tsai wrote:
> > On Thu, Aug 29, 2019 at 05:27:22PM +0200, Christian Brauner wrote:
> > > On Thu, Aug 29, 2019 at 09:53:59AM -0400, Joel Fernandes wrote:
> > > > On Thu, Aug 29, 2019 at 08:42:29AM +0200, Greg KH wrote:
> > > > > On Thu, Aug 29, 2019 at 01:49:53PM +0800, Peikan Tsai wrote:
> > > > [snip]
> > > > > > The allocated size for each binder_thread is 512 bytes by kzalloc.
> > > > > > Because the size of binder_thread is fixed and it's only 304 bytes.
> > > > > > It will save 208 bytes per binder_thread when use create a kmem_cache
> > > > > > for the binder_thread.
> > > > >
> > > > > Are you _sure_ it really will save that much memory? You want to do
> > > > > allocations based on a nice alignment for lots of good reasons,
> > > > > especially for something that needs quick accesses.
> > > >
> > > > Alignment can be done for slab allocations, kmem_cache_create() takes an
> > > > align argument. I am not sure what the default alignment of objects is
> > > > though (probably no default alignment). What is an optimal alignment in your
> > > > view?
> > >
> > > Probably SLAB_HWCACHE_ALIGN would make most sense.
> > >
> >
> > Agree. Thanks for yours comments and suggestions.
> > I'll put SLAB_HWCACHE_ALIGN it in patch v2.
> >
> > > >
> > > > > Did you test your change on a system that relies on binder and find any
> > > > > speed improvement or decrease, and any actual memory savings?
> > > > >
> > > > > If so, can you post your results?
> > > >
> > > > That's certainly worth it and I thought of asking for the same, but spoke too
> > > > soon!
> > >
> > > Yeah, it'd be interesting to see what difference this actually makes.
> > >
> > > Christian
> >
> > I tested this change on an Android device(arm) with AOSP kernel 4.19 and
> > observed
> > memory usage of binder_thread. But I didn't do binder benchmark yet.
> >
> > On my platform the memory usage of binder_thread reduce about 90 KB as
> > the
> > following result.
> > nr obj obj size total
> > before: 624 512 319488 bytes
> > after: 728 312 227136 bytes
>
> You have more objects???
>
Sorry, it's total objects which include some inactive objects ...
And because I tested it on an Android platform so there may be some noise.
So I try 'adb stop' and 'echo 3 > /proc/sys/vm/drop_caches' before starting
test to reduce the noise, and the result are as following.
objs
kzalloc 220 (kmalloc-512 alloc by binder_get_thread)
active_objs total objs objperslab slabdata
kmem_cache 194 403 13 31
Seems there are more objects when use kmemcache for binder_thread...
But as I understand it, those inactive objects can be free by kmemcahe shrink?
Also, I tested the throughput by using performace test of Android VTS.
size(bytes) kzalloc(byte/ns) kmemcache(byte/ns)
4 0.17 0.17
8 0.33 0.32
16 0.66 0.66
32 1.36 1.42
64 2.66 2.61
128 5.4 5.26
256 10.29 10.77
512 21.51 21.36
1k 41 40.26
2k 82.12 80.28
4k 149.24 146.95
8k 262.34 256
16k 417.96 422.2
32k 596.66 590.23
64k 600.84 601.25
next prev parent reply other threads:[~2019-09-02 14:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 5:49 [PATCH] binder: Use kmem_cache for binder_thread Peikan Tsai
2019-08-29 6:42 ` Greg KH
2019-08-29 13:53 ` Joel Fernandes
2019-08-29 15:27 ` Christian Brauner
2019-08-29 18:59 ` Peikan Tsai
2019-08-29 19:30 ` joel
2019-08-30 6:39 ` Greg KH
2019-09-02 14:12 ` Peikan Tsai [this message]
2019-08-30 6:38 ` Greg KH
2019-08-30 12:12 ` Christian Brauner
2019-08-29 13:43 ` Joel Fernandes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190902141225.GA21112@mark-All-Series \
--to=peikantsai@gmail.com \
--cc=arve@android.com \
--cc=christian.brauner@ubuntu.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=tkjos@android.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).