From: Carlos Llamas <cmllamas@google.com>
To: Lei Liu <liulei.rjpt@vivo.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Christian Brauner" <brauner@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
linux-kernel@vger.kernel.org, opensource.kernel@vivo.com
Subject: Re: [PATCH v4] binder_alloc: Replace kcalloc with kvcalloc to mitigate OOM issues
Date: Wed, 19 Jun 2024 23:44:09 +0000 [thread overview]
Message-ID: <ZnNtSVyBfb_4HlVK@google.com> (raw)
In-Reply-To: <20240619113841.3362-1-liulei.rjpt@vivo.com>
On Wed, Jun 19, 2024 at 07:38:40PM +0800, Lei Liu wrote:
> In binder_alloc, there is a frequent need for order3 memory allocation,
> especially on small-memory mobile devices, which can lead to OOM and
> cause foreground applications to be killed, resulting in flashbacks.
>
> We use kvcalloc to allocate memory, which can reduce system OOM
> occurrences, as well as decrease the time and probability of failure for
> order3 memory allocations. Additionally, It has little impact on the
> throughput of the binder. (as verified by Google's binder_benchmark
> testing tool).
>
> We have conducted multiple tests on an 8GB memory phone, kvcalloc has
> little performance degradation and resolves frequent OOM issues, Below
> is a partial excerpt of the test data.
>
> throughput(TH_PUT) = (size * Iterations)/Time
> kcalloc->kvcalloc:
>
> Sample with kcalloc():
> adb shell stop/ kcalloc /8+256G
> ---------------------------------------------------------------------
> Benchmark Time CPU Iterations TH-PUT TH-PUTCPU
> (ns) (ns) (GB/s) (GB/s)
> ---------------------------------------------------------------------
> BM_sendVec_binder4 39126 18550 38894 3.976282 8.38684
> BM_sendVec_binder8 38924 18542 37786 7.766108 16.3028
> BM_sendVec_binder16 38328 18228 36700 15.32039 32.2141
> BM_sendVec_binder32 38154 18215 38240 32.07213 67.1798
> BM_sendVec_binder64 39093 18809 36142 59.16885 122.977
> BM_sendVec_binder128 40169 19188 36461 116.1843 243.2253
> BM_sendVec_binder256 40695 19559 35951 226.1569 470.5484
> BM_sendVec_binder512 41446 20211 34259 423.2159 867.8743
> BM_sendVec_binder1024 44040 22939 28904 672.0639 1290.278
> BM_sendVec_binder2048 47817 25821 26595 1139.063 2109.393
> BM_sendVec_binder4096 54749 30905 22742 1701.423 3014.115
> BM_sendVec_binder8192 68316 42017 16684 2000.634 3252.858
> BM_sendVec_binder16384 95435 64081 10961 1881.752 2802.469
> BM_sendVec_binder32768 148232 107504 6510 1439.093 1984.295
> BM_sendVec_binder65536 326499 229874 3178 637.8991 906.0329
> NORAML TEST SUM 10355.79 17188.15
> stressapptest eat 2G SUM 10088.39 16625.97
>
> Sample with kvcalloc():
> adb shell stop/ kvcalloc /8+256G
> ----------------------------------------------------------------------
> Benchmark Time CPU Iterations TH-PUT TH-PUTCPU
> (ns) (ns) (GB/s) (GB/s)
> ----------------------------------------------------------------------
> BM_sendVec_binder4 39673 18832 36598 3.689965 7.773577
> BM_sendVec_binder8 39869 18969 37188 7.462038 15.68369
> BM_sendVec_binder16 39774 18896 36627 14.73405 31.01355
> BM_sendVec_binder32 40225 19125 36995 29.43045 61.90013
> BM_sendVec_binder64 40549 19529 35148 55.47544 115.1862
> BM_sendVec_binder128 41580 19892 35384 108.9262 227.6871
> BM_sendVec_binder256 41584 20059 34060 209.6806 434.6857
> BM_sendVec_binder512 42829 20899 32493 388.4381 796.0389
> BM_sendVec_binder1024 45037 23360 29251 665.0759 1282.236
> BM_sendVec_binder2048 47853 25761 27091 1159.433 2153.735
> BM_sendVec_binder4096 55574 31745 22405 1651.328 2890.877
> BM_sendVec_binder8192 70706 43693 16400 1900.105 3074.836
> BM_sendVec_binder16384 96161 64362 10793 1838.921 2747.468
> BM_sendVec_binder32768 147875 107292 6296 1395.147 1922.858
> BM_sendVec_binder65536 330324 232296 3053 605.7126 861.3209
> NORAML TEST SUM 10033.56 16623.35
> stressapptest eat 2G SUM 9958.43 16497.55
>
> Signed-off-by: Lei Liu <liulei.rjpt@vivo.com>
>
> ---
This looks great, thanks for the hard work!
Acked-by: Carlos Llamas <cmllamas@google.com>
prev parent reply other threads:[~2024-06-19 23:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 11:38 Lei Liu
2024-06-19 23:44 ` Carlos Llamas [this message]
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=ZnNtSVyBfb_4HlVK@google.com \
--to=cmllamas@google.com \
--cc=arve@android.com \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liulei.rjpt@vivo.com \
--cc=maco@android.com \
--cc=opensource.kernel@vivo.com \
--cc=surenb@google.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
Powered by JetHome