Hi Linus,
Am 10.07.2021 um 09:18 schrieb Linus Torvalds:
On Fri, Jul 9, 2021 at 2:08 PM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
The 8 byte copies are by far the majority.
llseek might actually not be unusual. And the timeval structure is - I
think - 8 bytes on 32-bit architectures and common for select timeouts
etc. And select/poll can be one of the most common system calls out
there depending on loads (usually graphical programs).
There's more const short reads in the old IDE code (1, 4 and 7 bytes,
the latter two in the ioctl syscall), and one 8 byte one in the libata
code (ata_get_identity()). None of this looks anywhere near performance
critical as llseek or select/poll.
But again - I don't think it's even worth worrying about in
architecture code. If you actually can measure it, I think we should
fix it in generic code rather than have architectures work around some
issue one by one.
I doubt it makes enough of a difference to measure, but maybe the llseek
impact is large enough to show in IO benchmarks. I'll run tests on
Christoph's latest patch series anyway so I'll have data to decide that.
I think the main issue for m68k should be "is it stable and works". At
least first. And then worry about copy_to/from_user() with a constant
size as a very very distant second concern.
So far, it looks like there's no regressions on either 030 or 040. Can't
see much difference on 060 other than its use of sfc/dfc in the ifpsp060
support code, but that's all inside 'unimplemented instruction' trap
handlers that can't be preempted AFAIK.
I'll ask Adrian to test these patches on 060 as well though.
Cheers,
Michael
Linus
