'td' vs sys/fs/nfsserver/

[Edward Napierala]

wt., 5 mar 2019 o 15:33 Konstantin Belousov <kostikbel at gmail.com> napisał(a):
>
> On Tue, Mar 05, 2019 at 09:26:43AM +0000, Edward Napierala wrote:
> > Hello.  As many of you know, right now, throughout the kernel,
> > there’s the ‘td’ argument being passed over and over, even though
> > we have a cheap way of accessing it by using ‘curthread’.  That’s
> > suboptimal for obvious reasons.  It can’t be fixed ‘just like that’,
> > as it would introduce a lot of code churn, and also possible bugs
> > in case we miss a case where the ‘td’ is not equal to curthread.
> > So, here's the big picture: this is what I'm _not_ intending
> > to do at this point.
> >
> > What I do intend doing is to go and try to fix it in a single kernel
> > component, the NFS server.  The idea: drop the ‘td’ argument (in
> > case of NFS server it’s usually spelled ‘p’ due to historical
> > reasons) where it’s unused, which turns out to be quite often, and
> > otherwise push ‘td’ down, function by function, so that when you
> > review it it’s obvious that it’s equal to curthread.  There are
> > three reasons to do this: first, it makes it very obvious that
> > the
td passed to various VOPs it calls is indeed always curthread,
> > and makes it easier to do the change described in the previous
> > paragraph, should someone try it.  Second… well, it’s a cleanup:
> > the NFS code passes it everywhere, and in many cases it's not used
> > at all.  Third, and this is the man reason: it’s a good way to test
> > the idea of pushing td down layer by layer without touching any
> > APIs that are not local to the NFS server, to see if it works, and
> > if it doesn't annoy people to much.  So, since I’ve been asked to
> > discuss it in public first: what do you guys think?
>
> Lets put aside the importance of the problem.
>
> I find the selection of the component to remove the 'td' argument somewhat
> strange.  It is on top of the VFS stack, so any VOPs or other VFS functions
> calls taking 'td' would require insertion of many curthread()s.  Why not
> start from the bottom ?
>
> I believe that looking at all in-tree filesystems and deciding which VOPs
> and VFS_XXX methods do not need td because they do not use it, would give
> more useful approach.  After td is elminated from VOPs which do not need
> it, it should be rather uncontended to eleminate td from corresponding
> callers of them.

At the bottom of the call stack the thread pointer usually gets used...
eventually.  Yes, that means we might end up accessing curthread
several times. But I'd expect it to be still much cheaper[1] to just use
curthread there, at the bottom, instead of passing the td over five
or ten levels of function calls to get there; not to mention more
readable.  Also, there's a common pattern of filesystem functions
calling global functions, which in turn back into filesystem
(eg ufs_accessx -> VOP_GETACL -> ufs_getacl -> vn_extattr_get
-> VOP_GETEXTATTR etc), which means doing it step by step
would introduce a lot of KPI changes, which is not something I'd
like to do.

Remember when we talked about it on IRC some... ten years ago?
I'm not sure, but I think it was you.  I've asked if the 'td' argument,
I think it was about the td argument to VOPs in general, was always
equal to curthread.  And the answer was "probably".  This means
I can't just safely ignore it and use curthread when I need it.
I mean, sure I can, but it might bite me in the end.  So the safe way
is to just keep passing it over and over again, everywhere, in newly
written code.

And thus the top-down approach.  Doing cleanup at the top first,
even without actually changing the public kernel KPIs, means
the 'probably' turns into 'yes', and in the new code I can stop
passing it over and over.


1. Where "much cheaper" means "it's unmeasurable anyway".