[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ymp63L22CQ2q8gsC@hyeyoo>
Date: Thu, 28 Apr 2022 20:30:36 +0900
From: Hyeonggon Yoo <42.hyeyoo@...il.com>
To: Joe Perches <joe@...ches.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, Marco Elver <elver@...gle.com>,
Matthew WilCox <willy@...radead.org>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <roman.gushchin@...ux.dev>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 12/23] mm/slab_common: cleanup kmalloc()
On Tue, Apr 26, 2022 at 11:00:32AM -0700, Joe Perches wrote:
> On Thu, 2022-04-14 at 17:57 +0900, Hyeonggon Yoo wrote:
> > Now that kmalloc() and kmalloc_node() do same job, make kmalloc()
> > wrapper of kmalloc_node().
>
> Why make every kmalloc larger object code size ?
>
> What is the overall object size change in a typical defconfig ?
Thank you for pointing this.
It increases every call to kmalloc() is increased (+5 bytes) due to
passing NUMA_NO_NODE. on x86_64's defconfig, the difference of vmlinux size is not that
visible because this patch also removes tracepoint.
But yeah, increasing 5 bytes for every caller seems questionable.
I'll think about this for a bit :)
Thanks!
--
Thanks,
Hyeonggon
Powered by blists - more mailing lists