From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 16:55:55 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5FC81065697 for ; Wed, 27 Aug 2008 16:55:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 650758FC1B for ; Wed, 27 Aug 2008 16:55:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so16146fgb.35 for ; Wed, 27 Aug 2008 09:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=sxlJ9RdAnFc9nWtLZnUyN2elnzx4B/xPtDzSpCCrlws=; b=Rk5VSRdLIRqL9ytuJVFIuvs/Ek9NJeQpfoqaWMPxFUjNgAVcI/rA2WTkSqF3DQaLkq ABEpiJO29f6bXi7I6eTqu2rxY4jJOoZuxn8ZhYQcazZJVPIC/JM8Ba9LL9yOXAptJesx wPtjAgLoQM4bJ5RdPiuuTv6gbWQBYMRbFAdOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=SRXmn149WUVuvFC0WFUVFerzxsZEPiUcqHqA3sQVuvbSrl+BlDAo07sE1k8wlgIwai MTF6vEB4SJNa2CZJGzAB2rJ/eNLgLvqSr0eDIzRpoWaPVuaQ86etMbfvVdqHQCzfhV2E A8+/c/E6mj9hc+iNIE5Ai06uzkCMhlEeM3g2I= Received: by 10.86.83.2 with SMTP id g2mr223585fgb.54.1219856153938; Wed, 27 Aug 2008 09:55:53 -0700 (PDT) Received: by 10.86.78.14 with HTTP; Wed, 27 Aug 2008 09:55:53 -0700 (PDT) Message-ID: <3bbf2fe10808270955y53b00587m1991e7bf898466e1@mail.gmail.com> Date: Wed, 27 Aug 2008 18:55:53 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "FreeBSD Arch" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: a8f997d86184c67c Cc: Konstantin Belousov Subject: Kernel decontextualization -- idea and little proof-of-concept X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 16:55:55 -0000 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