Re: [PATCH] iov_iter: optimise iter type checking

On 09/01/2021 21:49, David Laight wrote:

From: Al Viro

quoted

Sent: 09 January 2021 17:04

On Sat, Jan 09, 2021 at 04:09:08PM +0000, Pavel Begunkov wrote:

quoted

On 06/12/2020 16:01, Pavel Begunkov wrote:

quoted

On 21/11/2020 14:37, Pavel Begunkov wrote:

quoted

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.

quoted

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