Re: RFC: New userspace fetch/store API

[Jason Thorpe <thorpej%me.com@localhost>]

> On Feb 26, 2019, at 9:41 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>> Memory store to initialize error
> 
> Heh.  Well spotted.
> 
>> Itâ??s 2 loads and a store in either case, [...]
> 
> ...though one does better when there _are_ multiple calls whose error
> checks can be collapsed.

...and having personally audited every call site for these in the kernel recently, that basically never happens.

>> and the second pattern is contrary to just about everything else in
>> the kernel.
> 
> True, though many, perhaps most, of those patterns are historical
> relics from the days when memory references were comparatively cheap.
> This is not to say that they necessarily should be discarded, just that
> "It's Tradition!" is not necessarily a conversation-closer.

At the same time, one mustn't arbitrarily micro-optimize every tiny little thing at the expense of code flow and API consistency.  Trust me, I completely understand the "death by a thousand tiny cuts" problem (it's something I deal with constantly at $DayJob), but this isn't one of those.

One also must consider what the intended use of these APIs are... while they are general purpose, any time you're fetching a single memory cell from another address space, you've already decided that the code isn't performance-critical.

Indeed, in the first intended use case of ufetch_int(), what started me down this rabbit hole in the first place, is the _slow path_ of a contended mutex acquisition.

In any case, I'm not going to spend any more time debating how values and errors are returned from these functions ... our time is better spent arguing about things that actually matter, such as wether or not "uint" should appear in the function names and whether or not disc brakes are appropriate for road racing bicycles.

-- thorpej