Received-SPF: pass (google.com: domain of linux-kernel+bounces-213350-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 13 Jun 2024 15:42:18 +0200
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Lei Liu <liulei.rjpt@vivo.com>
Cc: Arve =?iso-8859-1?B?SGr4bm5lduVn?= <arve@android.com>,
	Todd Kjos <tkjos@android.com>, Martijn Coenen <maco@android.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Christian Brauner <brauner@kernel.org>,
	Carlos Llamas <cmllamas@google.com>,
	Suren Baghdasaryan <surenb@google.com>,
	linux-kernel@vger.kernel.org, opensource.kernel@vivo.com
Subject: Re: [PATCH] binder_alloc: replace kcalloc with kvcalloc to mitigate
 OOM issues
Message-ID: <2024061359-deniable-boundless-96c3@gregkh>
References: <20240611085629.25088-1-liulei.rjpt@vivo.com>
 <2024061216-faster-cufflink-ceac@gregkh>
 <39eaba63-0e18-439a-82ac-834505e6473e@vivo.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <39eaba63-0e18-439a-82ac-834505e6473e@vivo.com>

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