Looking at VFS (but this is not a VFS-only e-mail), what immediately
pops up is that KPI is rather heavy, someway complicated and too
little user-friendly (in particular in regard of locking). Some of
this heaviness cames from direct approaching some peculiar problems
(vnodes recycling in primis) but another part is totally old-standing
and cames out from wrong (or anyways acrossed) assumptions.
One of this latter case is the widespread presence of "thread"
arguments in the whole kernel. Among all the subsystems, the most
plagued is the VFS. You can see a lot of unuseful (or partially,
better explained later) thread passed all over the VOP_* functions,
their consumers and their callee and this reflects on a lot of key
structures too (uio, componentname, namei, etc.).

My idea is that we should drop totally this thread bloat from our
subsystems (and in particular from VFS) because it is nosense and it
adds just obfuscation and overhead for eventual consumer of the KPI.
This also will prepare a better ground for further VFS improvements
like, for example, namei KPI refactoring and reorganization, file
accessings, etc.

Small Q&A about possible concerns:
Q: Sometimes we need to pass a thread in order to get his credentials,
how you will handle this?
A: We will simply get the ucred pointed and will switch the thread
argument to be a credential

Q: curthread accesses are heavy, will this work penalyze kernel performances?
A: This work is intended in order to drastically reduce thread
pointers movement. This means that, ideally, this will get in having a
lot less curthread accesses than the old code.

Q: Ideally, you have to complete the whole work fastly but still
keeping patches in mealpieces that people can review and test, how do
you plan to handle this?
A: There is not a simple solution for this. I will try to put a lot of
effort in order to have good-sized patches and to do it as fast as I
can.
For an example, please, look at this patch:
http://www.freebsd.org/~attilio/vfsattr.diff

which does remove the thread argument from VOP_GETATTR / VOP_SETATTR
couplet. There is still room for refinements here, but I need to
cleanup other VOP_* functions before.

Q: You have been good in avoiding the biggest concern, but here we go!
What about MFC troubles caming from a massive KPI breakage?
A: I know that MFC to 7 and 6 will became a PITA (in particular for
VFS consumers) but this is a good moment in order to decide if we want
to keep catering a old-standing (bogus) approach like that or if we
want to operate a full cleanup. This will mean working also in the
variety of consumers filesystem but with the help of a good line-up of
testers I think I can handle this.

Let me know what do you think about.

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

On Wed, 27 Aug 2008, Attilio Rao wrote:

> Small Q&A about possible concerns:
> Q: Sometimes we need to pass a thread in order to get his credentials,
> how you will handle this?
> A: We will simply get the ucred pointed and will switch the thread
> argument to be a credential

I tend to agree with the approach you are proposing, and have been considering
similar changes for the network stack for much the same reasons. Thre points:

(1) We may need to explicitly pass one or more credentials in places where we
don't currently do so. This is certainly true in the network stack, and
similar considerations in VFS wouldn't surprise me. Most frequently, this
construct is used when work occurs in an asynchronous context from the
requesting thread and use of the original authorizing credential is
required.

(2) Keep a careful eye out for cases where an implicit use of the passed
thread is to establish context for copyin(9). You might argue that
copyin(9) should accept an address space or thread argument and then
assert that it is the current one...

(3) Take a look at the on-going virtualization work, as we may want to apply
the same virtualization techniques to VFS in the future, in which case
we'll need to make sure that the approaches are compatible.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"