Re: [PATCH] iov_iter: optimise iter type checking

[Pavel Begunkov]

On 09/01/2021 21:49, David Laight wrote:
> From: Al Viro
>> Sent: 09 January 2021 17:04
>>
>> On Sat, Jan 09, 2021 at 04:09:08PM +0000, Pavel Begunkov wrote:
>>> On 06/12/2020 16:01, Pavel Begunkov wrote:
>>>> On 21/11/2020 14:37, Pavel Begunkov wrote:
>>>>> The problem here is that iov_iter_is_*() helpers check types for
>>>>> equality, but all iterate_* helpers do bitwise ands. This confuses
>>>>> compilers, so even if some cases were handled separately with
>>>>> iov_iter_is_*(), corresponding ifs in iterate*() right after are not
>>>>> eliminated.
>>>>>
>>>>> E.g. iov_iter_npages() first handles discards, but iterate_all_kinds()
>>>>> still checks for discard iter type and generates unreachable code down
>>>>> the line.
>>>>
>>>> Ping. This one should be pretty simple
>>>
>>> Ping please. Any doubts about this patch?
>>
>> Sorry, had been buried in other crap.  I'm really not fond of the
>> bitmap use; if anything, I would rather turn iterate_and_advance() et.al.
>> into switches...
> 
> That loses any optimisations in the order of the comparisons.
> The bitmap also allows different groups to be optimised for in different code paths.

You still can have a fast path and even retoss ITER_* for convenience.
Other use cases are not important at the current state.

> 
>> How about moving the READ/WRITE part into MSB?  Checking is just as fast
>> (if not faster - check for sign vs. checking bit 0).  And turn the
>> types into straight (dense) enum.
> 
> Does any code actually look at the fields as a pair?
> Would it even be better to use separate bytes?
> Even growing the on-stack structure by a word won't really matter.

u8 type, rw;

That won't bloat the struct. I like the idea. If used together compilers
can treat it as u16.

btw there is a 4B hole just after for x64.

-- 
Pavel Begunkov