[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjM6KwAvC9+sCAm9BgBSspZm60VBLzHcuonGcHrPKJrbw@mail.gmail.com>
Date: Sun, 3 Sep 2023 20:07:21 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, bp@...en8.de
Subject: Re: [PATCH v2] x86: bring back rep movsq for user access on CPUs
without ERMS
On Sun, 3 Sept 2023 at 16:15, Mateusz Guzik <mjguzik@...il.com> wrote:
>
> bad news: virtually no difference for stat(2) (aka newfstatat)
> before: 3898139
> after: 3922714 (+0%)
Yeah, the path lookup is way more expensive than a slight win in a L1
copy, and the pathname lookup will also have gone much deeper on the
stack.
> ok news: a modest win for the actual fstat system call (aka newfstat,
> *not* the libc wrapper calling newfstatat)
> before: 8511283
> after: 8746829 (+2%)
We might end up with slightly less deep stack, so potentially a
smaller cache footprint, and there is much less other stuff going on..
> The patch as proposed is kind of crap -- moving all that handling out
> of fs/stat.c is quite weird and trivially avoidable, with a way to do
> it already present in the file.
So you say. I claim that you're full of crap.
Try it and you'll see it is not even *remotely* as easy as you claim.
Not when you have to deal with random sizes and padding of 20+
different architectures.
Linus
Powered by blists - more mailing lists