From: Minchan Kim <minchan@kernel.org>
To: Ganesh Mahendran <opensource.ganesh@gmail.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"Joe Perches" <joe@perches.com>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@google.com>,
"Martijn Coenen" <maco@android.com>
Subject: Re: [PATCH v5] ANDROID: binder: change down_write to down_read
Date: Mon, 2 Apr 2018 16:11:33 +0900 [thread overview]
Message-ID: <20180402071133.GA62369@rodete-desktop-imager.corp.google.com> (raw)
In-Reply-To: <CADAEsF8_vptm7p2y2ekj8m6t=bz4pwC1+np7r2-YnAKbnEsA4w@mail.gmail.com>
On Mon, Apr 02, 2018 at 02:46:14PM +0800, Ganesh Mahendran wrote:
> 2018-04-02 14:34 GMT+08:00 Minchan Kim <minchan@kernel.org>:
> > On Fri, Mar 30, 2018 at 12:04:07PM +0200, Greg Kroah-Hartman wrote:
> >> On Fri, Mar 30, 2018 at 10:29:21AM +0900, Minchan Kim wrote:
> >> > Hi Ganesh,
> >> >
> >> > On Fri, Mar 30, 2018 at 09:21:55AM +0800, Ganesh Mahendran wrote:
> >> > > 2018-03-29 14:54 GMT+08:00 Minchan Kim <minchan@kernel.org>:
> >> > > > binder_update_page_range needs down_write of mmap_sem because
> >> > > > vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless
> >> > > > it is set. However, when I profile binder working, it seems
> >> > > > every binder buffers should be mapped in advance by binder_mmap.
> >> > > > It means we could set VM_MIXEDMAP in binder_mmap time which is
> >> > > > already hold a mmap_sem as down_write so binder_update_page_range
> >> > > > doesn't need to hold a mmap_sem as down_write.
> >> > > >
> >> > > > Android suffers from mmap_sem contention so let's reduce mmap_sem
> >> > > > down_write.
> >> > >
> >> > > Hi, Minchan:
> >> > >
> >> > > It seems there is performance regression of this patch.
> >> >
> >> > You mean "This patch aims for solving performance regression" not "This patch
> >> > makes performance regression"?
> >> >
> >> > >
> >> > > Do you have some test result of android app launch time or binderThroughput?
> >> >
> >> > Unfortunately, I don't have any number. The goal is to reduce the number of
> >> > call mmap_sem as write-side lock because it makes priority inversion of threads
> >> > easily and that's one of clear part I spot that we don't need write-side lock.
> >>
> >> Please always run the binderThroughput tests when making binder changes
> >> (there is a binder test suite in the CTS Android tests), as that ensures
> >> that you are not causing performance regressions as well as just normal
> >> bug regressions :)
> >
> > Thanks for the information. I didn't notice that such kinds of tests for
> > binder. I will keep it in mind.
> >
> > Today, I have setup the testing for my phone and found testing was very
> > fluctuating even without my patch. It might be not good with my test
> > skill. I emulated user's behavior with various touch event. With it, I open
> > various apps and play with them several times. Before starting the test,
> > I did "adb shell stop && adb shell start && echo 3 > /proc/sys/vm/drop_caches"
> >
> > Such 15% noise was very easy to make it.
> >
> > Ganesh, How did you measure? What's the stddev?
>
> Hi, Minchan:
>
> Sorry for the late response, a little busy these days. :)
>
> We have our own test tools to measure app launch time, or you can use
> android systrace to get the app launch time. We tested your V1 patch:
> https://patchwork.kernel.org/patch/10312057/
> and found app lunch time regression.
V1 had a bug with VM_MAYWRITE. Could you confirm it with v5?
Please tell me more detail. What apps are slower compared to old?
Every apps are slowed with avg 15%? Then, what's the stddev?
The reason I'm asking is as I mentioned, it would be caused by rw_semaphore
implementation and priority of threads which calls binder operation so I
guess it would be not deterministic.
When I had an simple experiment, it was very fluctuating as I expected.
(the testing enviroment might be not good in my side).
If it's real problem on real practice, better fix is not using write_lock
of mmap_sem(it's abusing the write-side lock) but should adjust priority,
I think. What do you think?
Anyway, before the further discussion, we should confirm the root cause.
>
> I will use binderThroghput tool to test the patch today or tomorrow.
>
Thanks. I will do.
next prev parent reply other threads:[~2018-04-02 7:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 6:54 Minchan Kim
2018-03-30 1:21 ` Ganesh Mahendran
2018-03-30 1:29 ` Minchan Kim
2018-03-30 1:39 ` Ganesh Mahendran
2018-03-30 2:40 ` Minchan Kim
2018-03-30 10:04 ` Greg Kroah-Hartman
2018-04-02 6:34 ` Minchan Kim
2018-04-02 6:46 ` Ganesh Mahendran
2018-04-02 7:11 ` Minchan Kim [this message]
2018-04-02 10:01 ` Ganesh Mahendran
2018-04-02 10:32 ` Minchan Kim
2018-04-09 6:40 ` Minchan Kim
2018-04-09 6:50 ` Ganesh Mahendran
2018-04-10 8:52 ` Ganesh Mahendran
2018-04-16 9:17 ` Minchan Kim
2018-04-16 9:37 ` Greg Kroah-Hartman
2018-04-16 9:40 ` Greg Kroah-Hartman
2018-04-16 10:03 ` Minchan Kim
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=20180402071133.GA62369@rodete-desktop-imager.corp.google.com \
--to=minchan@kernel.org \
--cc=arve@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=opensource.ganesh@gmail.com \
--cc=tkjos@google.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
all inboxes | Powered by JetHome®