linux-kernel - Re: [PATCH] binder_alloc: replace kcalloc with kvcalloc to mitigate OOM issues

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] [day] [month] [year] [list]

Message-ID: <2024061359-deniable-boundless-96c3@gregkh>
Date: Thu, 13 Jun 2024 15:42:18 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Lei Liu <liulei.rjpt@...o.com>
Cc: Arve Hjønnevåg <arve@...roid.com>,
	Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>,
	Joel Fernandes <joel@...lfernandes.org>,
	Christian Brauner <brauner@...nel.org>,
	Carlos Llamas <cmllamas@...gle.com>,
	Suren Baghdasaryan <surenb@...gle.com>,
	linux-kernel@...r.kernel.org, opensource.kernel@...o.com
Subject: Re: [PATCH] binder_alloc: replace kcalloc with kvcalloc to mitigate
 OOM issues

On Thu, Jun 13, 2024 at 08:01:39PM +0800, Lei Liu wrote:
> On 2024/6/12 17:58, Greg Kroah-Hartman wrote:
> > On Tue, Jun 11, 2024 at 04:56:28PM +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 can also improve the throughput of binder (as verified by
> > > Google's binder_benchmark testing tool). We have conducted multiple
> > > tests on an 8GB memory phone, and the performance of kvcalloc is
> > > better. Below is a partial excerpt of the test data. throughput =
> > > (size * Iterations)/Time Benchmark-kvcalloc Time CPU Iterations
> > > throughput(Gb/s)
> > > ----------------------------------------------------------------
> > > BM_sendVec_binder-4096 30926 ns 20481 ns 34457 4563.66↑
> > > BM_sendVec_binder-8192 42667 ns 30837 ns 22631 4345.11↑
> > > BM_sendVec_binder-16384 67586 ns 52381 ns 13318 3228.51↑
> > > BM_sendVec_binder-32768 116496 ns 94893 ns 7416 2085.97↑
> > > BM_sendVec_binder-65536 265482 ns 209214 ns 3530 871.40↑
> > > Benchmark-kvcalloc Time CPU Iterations throughput(Gb/s)
> > Both benchmarks are the same? Or is this labeled incorrectly?
> I'm really sorry, I got the title of the table wrong, here are the updated
> data:
> throughput = (size * Iterations)/Time
> kvcalloc->kvmalloc:
> Benchmark-kvcalloc    Time    CPU    Iterations    throughput(Gb/s)
> ----------------------------------------------------------------
> BM_sendVec_binder-4096    30926 ns    20481 ns    34457    4563.66↑
> BM_sendVec_binder-8192    42667 ns    30837 ns    22631    4345.11↑
> BM_sendVec_binder-16384    67586 ns    52381 ns    13318    3228.51↑
> BM_sendVec_binder-32768    116496 ns    94893 ns    7416    2085.97↑
> BM_sendVec_binder-65536    265482 ns    209214 ns    3530    871.40↑
> 
> kcalloc->kmalloc
> Benchmark-kcalloc    Time    CPU    Iterations    throughput(Gb/s)
> ----------------------------------------------------------------
> BM_sendVec_binder-4096    39070 ns    24207 ns    31063    3256.56
> BM_sendVec_binder-8192    49476 ns    35099 ns    18817    3115.62
> BM_sendVec_binder-16384    76866 ns    58924 ns    11883    2532.86
> BM_sendVec_binder-32768    134022 ns    102788 ns    6535    1597.78
> BM_sendVec_binder-65536    281004 ns    220028 ns    3135    731.14

Great, can you please resend this as a new version?

thanks,

greg k-h