Date: Wed, 27 Aug 2008 18:55:53 +0200 From: "Attilio Rao" <attilio@freebsd.org> To: "FreeBSD Arch" <arch@freebsd.org> Cc: Konstantin Belousov <kib@freebsd.org> Subject: Kernel decontextualization -- idea and little proof-of-concept Message-ID: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10808270955y53b00587m1991e7bf898466e1>