From owner-freebsd-chat@FreeBSD.ORG Mon Jan 12 11:46:57 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D5A416A4CE; Mon, 12 Jan 2004 11:46:57 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B0B943D46; Mon, 12 Jan 2004 11:46:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0CJkrtV054273; Mon, 12 Jan 2004 11:46:53 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0CJkqOE054272; Mon, 12 Jan 2004 11:46:52 -0800 (PST) (envelope-from dillon) Date: Mon, 12 Jan 2004 11:46:52 -0800 (PST) From: Matthew Dillon Message-Id: <200401121946.i0CJkqOE054272@apollo.backplane.com> To: "" References: <200401062000.i06K0hSI012184@dyson.jdyson.com> <200401072317.i07NHaM9065411@apollo.backplane.com> <3FFD01CE.5070301@energyhq.es.eu.org> <1073680797.3fff119d89733@webmail.iquest.net> cc: freebsd-chat@freebsd.org cc: freebsd-hackers@freebsd.org cc: Munden Randall J cc: jsd@jdyson.com Subject: Re: Where is FreeBSD going? X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 19:46:57 -0000 :> Agreed. Like I've said, the main problem I see is complexity. It :> wouldn't matter as much if there were 5-10 people with deep knowledge of :> SMPng, but with 1 or 2 hackers working on it, the chance that everything :> will be ever fixed is quite small. :> :IMO, the easiest way to start the SMP work (from a FreeBSD monolithic :approach), is to flatten as much of the VFS/VM code as possible into :a continuation scheme... That is something that I could have done 5yrs :ago in a few weeks, and then keep the networking system as it is. :There would be shims deployed that would still support the sleep/wakeup :scheme, so that the non-networking could and the new flat interface could :be debugged... (It is NOT a good idea to bug the networking guys until :the new scheme would be debugged.) : :At that point, there would be a code with explicit context carried around, :and no nesting or stack context. This would have a small benefit of avoiding :multiple deeply nested kernel stacks... : :Given the very flat scheme, each subsystem could be recoded into a :message passing or simple continuation scheme (whatever is appropriate.) :The system would be naturally able to be reworked -- without the :hidden dependencies of the stack. VFS/VM layering problems then :become resolvable. : :This is NOT a total solution, but should be the beginning of a thinking :exercise that seems to lead into the correct direction. (Don't :criticize this based upon the completeness of my prescription, but :on what can eventually be developed!!!) I have been trying to figure out how to implement asynch system calls in DFly, which is a very similar problem to the one posed by the VFS stack. I don't think we can use a pure continuation scheme, but I do think the required context can be minimized enough to fit in a structure. In DFly, the natural structure to hold the contextual information is the message structure that was used to initiate the operation in the first place. So, in regards to async system calls, the message structure contains an additional union that lays out contextual storage requirements for each system call. For example, the contextual information required to support nanosleep() would primarily be a timeout structure. (This is in fact the only system call that can be run asynch in DFly at the moment... I am using it as an experimental base to try to refine the code requirements to reduce complexity). The blocking points for both system calls and VFS calls (which are the real problem being solved here) tend to be related to blocking on I/O events, locks, and mutexes. In DFly I primarily have to worry about I/O events and locks and not so much about mutexes. Also, in DFly, We are serializing many major subsystems and segregating high performance structures, such as PCB's, by associating them with a single thread. This fits very well with the continuation scheme idea because we would prefer to have only a few threads which handle multiple data structures (to make best use of available cpus), and this means that we cannot simply 'block' in such threads whenever we feel like it without screwing up parallelism. -Matt Matthew Dillon :Oh well -- I cannot think too much about this stuff, or I'll actually :get emotionally involved again. I need to get a 'normal' job, not :working at home and need to interact with people instead of CRTs. :-). :(I give a sh*t about FreeBSD, and hope that WHATEVER problems that :truly exist are fully resolved.) There is alot of blood sweat and :tears in that codebase, and being involved in the project should be :done with great respect. : :John