[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <msw3w26o27g2lvdgche535m47vqdzmr4g2evq5gc4uvmo5fqi2@bedh4opzimmt>
Date: Mon, 19 Feb 2024 16:38:16 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: David Laight <David.Laight@...lab.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
Arnd Bergmann <arnd@...db.de>, Calvin Owens <jcalvinowens@...il.com>,
Dave Martin <Dave.Martin@....com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-bcachefs@...r.kernel.org" <linux-bcachefs@...r.kernel.org>
Subject: Re: [PATCH] arm: Silence gcc warnings about arch ABI drift
On Mon, Feb 19, 2024 at 07:53:15PM +0000, David Laight wrote:
> ...
> > I'm not always trying to write code that will generate the fastest
> > assembly possible; there aro other considerations. As long a the
> > compiler is doing something /reasonable/, the code is fine.
>
> Speaks the man who was writing horrid 'jit' code ...
>
> This also begs the question of why that data is so compressed
> in the first place?
> It is quite likely that a few accesses generate far more code
> than the data you are attempting to save.
It's easy to understand if you understand profiling, benchmarking and
cache effects.
That 'jit code' is for _all_ filesystem metadata.
Powered by blists - more mailing lists