[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230731070954.fb3tez2dsusikwn4@localhost>
Date: Mon, 31 Jul 2023 09:09:54 +0200
From: Joel Granados <j.granados@...sung.com>
To: Luis Chamberlain <mcgrof@...nel.org>
CC: Joerg Reuter <jreuter@...na.de>,
Ralf Baechle <ralf@...ux-mips.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, <willy@...radead.org>,
<keescook@...omium.org>, <josh@...htriplett.org>,
<linux-hams@...r.kernel.org>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/14] ax.25: Update to register_net_sysctl_sz
On Fri, Jul 28, 2023 at 11:16:06AM -0700, Luis Chamberlain wrote:
> On Fri, Jul 28, 2023 at 09:35:36AM +0200, Joel Granados wrote:
> > On Thu, Jul 27, 2023 at 08:44:24AM -0700, Luis Chamberlain wrote:
> > > On Thu, Jul 27, 2023 at 02:31:12PM +0200, Joel Granados wrote:
> > > > There are no deltas in this patch set. We start seeing the deltas when
> > > > we start removing with the next 6 chunks. I'll try to make that more
> > > > clear in the commit message.
> > >
> > > Indeed, even if no deltas are created it is importan then to say that.
> > > If there are no deltas the "why" becomes more important. If the why is
> > > to make it easier to apply subsequent patches, that must be said. When
> > yes. The why for this patch set in particular is to make it easier to
> > apply the sentinel removal patches.
> >
> > I think the difficulty for me comes from having two whys: 1. The one for
> > this patch set which is to make it easier to apply sentinel removal patches. And 2.
> > The one for the "big" patch (that actually removes the sentinels) which is to
> > reduce build time size and run time memory bloat.
>
> The 2) is part of the real why, 1) is more of how to do 2) cleanly. But
> the real why is the savings in memory because we are moving arrays out
> of kernel/sysctl.c so we don't want to incur a size penalty. The
> collateral to avoid increasing size in the moves also proves to save us
> more memory overall, on the ballpark of about 64 bytes per array in the
> kernel both at runtime and build time. The build time gain is mostly
> on the __init stuff and so gets freed right away, but since sysctl
> code always kzallocs the arrays passed we also save 64 bytes per array
> in the end at runtime.
Yes. In my new version I have tried to mention both 1 and 2 and
differentiate between them. I stuck with the "why" for this patch set is
to make it easier to reach 2.
I'll send it out today.
>
> Luis
--
Joel Granados
Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)
Powered by blists - more mailing lists