Date: Thu, 28 Feb 2002 20:33:14 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.org>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.org>, Julian Elischer <julian@elischer.org> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <XFMail.020228203314.jhb@FreeBSD.org> In-Reply-To: <200202281845.g1SIj0U37687@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <dillon@backplane.com> > >:> >:> 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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ >:> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >:> > > -- John Baldwin <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020228203314.jhb>