From owner-freebsd-current Thu Feb 28 17:34:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 9DC5837B420 for ; Thu, 28 Feb 2002 17:33:55 -0800 (PST) Received: (qmail 30647 invoked from network); 1 Mar 2002 01:33:50 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.152.157]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Mar 2002 01:33:50 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g211XLG42458; Thu, 28 Feb 2002 20:33:21 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200202281845.g1SIj0U37687@apollo.backplane.com> Date: Thu, 28 Feb 2002 20:33:14 -0500 (EST) From: John Baldwin To: Matthew Dillon Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Cc: Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 28-Feb-02 Matthew Dillon wrote: > Not to put too fine a point on it, but, I don't see how this can > possibly justify preventing me from committing my critical_*() stuff. > You've just stated publically that your preemption stuff is unusable > as it currently stands. Why am I supposed to wait an arbitrary period > of time for you to fix, test, and commit it? > > I would REALLY like to commit my critical_*() stuff, and for the record > this will also include the stage-2 stuff described in the original commit > comments that will be made a few days after the current commit. Because the critical_* changes you are doing don't match up to the overall design. See my mail to -arch for more on that though. At some point in the future I think that this work can fit in rather well to the cpu_critical_foo stuff (which can be split out from critical_enter/exit now). However, at this stage I would rather avoid complex optimizations of APIs that may change in the future. There is more to be gained from locking subsystems. > -Matt > Matthew Dillon > > >:> >:> Preemptive kernels don't even make it out of single user mode for SMP >:> machines, >:> ok? We aren't talking minor breakage here, we are talking _extreme_ >:> breakage. >:> If people want to play with it, preempt.patch on freefall is updated via a >:> cron >:> job every half hour or so. Unfortunately, however, it's in a limbo atm due >:> to >:> KSE and needing to sort out how the priorities are going to work. It will >:> really be better to let KSE settle into the scheduler first adn then add >:> preemption to the scheduler itself afterwards. >:> >:> The reason I'm not pushing preemption into the tree fully (I've already >:> committed half of the original patch) is that there is other work (proc >:> locking >:> for example) that gets us more bang for the buck. >:> >:> -- >:> >:> John Baldwin <>< http://www.FreeBSD.org/~jhb/ >:> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >:> > > -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message