lkml.org 
[lkml]   [2021]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: add ___GFP_NOINIT flag which disables zeroing on alloc
On Mon, Mar 29, 2021 at 07:12:55PM +0900, Hyunsoon Kim wrote:
> On Mon, Mar 29, 2021 at 09:34:31AM +0300, Leon Romanovsky wrote:
> > On Mon, Mar 29, 2021 at 02:29:10PM +0900, Hyunsoon Kim wrote:
> > > This patch allows programmer to avoid zero initialization on page
> > > allocation even when the kernel config "CONFIG_INIT_ON_ALLOC_DEFAULT"
> > > is enabled. The configuration is made to prevent uninitialized
> > > heap memory flaws, and Android has applied this for security and
> > > deterministic execution times. Please refer to below.
> > >
> > > https://android-review.googlesource.com/c/kernel/common/+/1235132
> > >
> > > However, there is a case that the zeroing page memory is unnecessary
> > > when the page is used on specific purpose and will be zeroed
> > > automatically by hardware that accesses the memory through DMA.
> > > For instance, page allocation used for IP packet reception from Exynos
> > > modem is solely used for packet reception. Although the page will be
> > > freed eventually and reused for some other purpose, initialization at
> > > that moment of reuse will be sufficient to avoid uninitialized heap
> > > memory flaws. To support this kind of control, this patch creates new
> > > gfp type called ___GFP_NOINIT, that allows no zeroing at the moment
> > > of page allocation, called by many related APIs such as page_frag_alloc,
> > > alloc_pages, etc.
> > >
> > > Signed-off-by: Hyunsoon Kim <h10.kim@samsung.com>
> > > ---
> > > include/linux/gfp.h | 2 ++
> > > include/linux/mm.h | 4 +++-
> > > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > Let's assume that we will use this new flag, and users are smart enough
> > to figure when it needs to be used, what will be the performance gain?
> >
> > Thanks
>
> For instance, there are four memory access (either read or write) done
> by the system; memory write due to page allocation for reserving memory
> for modem hardware, memory write on the page by modem hardware,
> read and write incurred by copy_to_user operation by iperf reading
> the incoming network data. Theoretically, we can expect 1/4 of power
> saving on DRAM bandwidth. By performing simple iperf test with download
> UDP 800Mbps, we saw 5-6mA power gain by disabling
> CONFIG_INIT_ON_ALLOC_DEFAULT.

I'm more interested to see real results.

Thanks

>
> Thanks


\
 
 \ /
  Last update: 2021-03-31 05:58    [W:0.043 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site