Re: [PATCH RFC v2] m68k: remove get_fs()/set_fs()

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Linus,

Am 10.07.2021 um 09:18 schrieb Linus Torvalds:
> On Fri, Jul 9, 2021 at 2:08 PM Michael Schmitz <schmitzmic@gmail.com> 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
>