Re: [PATCH RFC 0/4] Encode NFSv4 attributes via a branch table

[Chuck Lever III <chuck.lever@oracle.com>]

> On Jul 3, 2023, at 12:48 AM, NeilBrown <neilb@suse.de> wrote:
> 
> On Fri, 30 Jun 2023, Chuck Lever wrote:
>> Here's something just for fun. I've converted nfsd4_encode_fattr4()
>> to use a bitmask loop, calling an encode helper for each attribute
>> to be encoded. Rotten tomatoes and gold stars are both acceptible.
> 
> Tomatoes or stars .... it is a hard choice :-)
> 
> I wonder what the compiler does with this code.
> If it unrolls the loop and inlines the functions - which it probably can
> do as the array of pointers is declared const - you end up with much the
> same result as the current code.
> 
> And I wonder where the compiler puts the code in each conditional now.
> If it assumes an if() is unlikely, then it would all be out-of-line
> which sounds like part of your goal (or maybe just a nice-to-have).
> 
> If the compiler does, or can be convinced to, do the unroll and inline
> and unlikely optimisations, then I think I'd give this a goal star.
> 
> I guess in practice some of the attributes are "likely" and many are
> "unlikely".

This is absolutely the case.

My first attempt at optimizing nfsd4_encode_fattr() was to build
a miniature version that handled just the frequently-requested
combinations of attributes. It made very little difference.

The conclusions that I drew from that are:

- The number of conditional branches in here doesn't seem to be
  the costly part of encode_fattr().

- The frequently-requested attributes are expensive to process
  for some reason. Size is easy, but getting the user and
  group are not as quick as I would have hoped.

- It's not the efficiency of encode_fattr() that is the issue,
  it's the frequency of its use. That's something the server
  can't do much about.


> With the current code we could easily annotate that if we
> wanted to and thought (or measured) there was any value.  With the
> looping code we cannot really annotate the likelihood of each.

Nope, likelihood annotation isn't really possible with a bitmask
loop. But my understanding is that unlikely() means really
really really unlikely, as in "this code is an error case that
is almost never used". And that's not actually the case for most
of these attributes.


> The code-generation idea is intriguing.  Even if we didn't reach that
> goal, having the code highly structured as though it were auto-generated
> would be no bad thing.

Maybe it just calms my yearning for an ordered universe to deal
with these attributes in the same way that we deal with COMPOUND
operations.

I appreciate the review!


--
Chuck Lever