Date: Wed, 5 Dec 2001 08:55:57 -0800 From: Luigi Rizzo <luigi@FreeBSD.ORG> To: Warner Losh <imp@harmony.village.org> Cc: Robert Watson <rwatson@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf options.i386 src/sys/i386/i386 swtch.s trap.c src/sys/net if.h netisr.h src/sys/sys systm.h src/sys/i386/include asnames.h src/sys/kern kern_clock.c src/sys/dev/fxp if_fxp.c src/sys/pci if_dc.c if_dcreg.h if_sis.c ... Message-ID: <20011205085557.B63639@iguana.aciri.org> In-Reply-To: <200112050852.fB58qrM79607@harmony.village.org> References: <Pine.NEB.3.96L.1011204102208.62227B-100000@fledge.watson.org> <200112050852.fB58qrM79607@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I have posted to -core a version of this code which is targeted to
-current, and I do plan to add it there as well.
I have not done the commit yet first because i got no reply from
core on the topic, secondly (and more importantly) because the
-current version does not perform as well as the one for -stable,
and might require some redesign.
In particular, the -stable version has a mechanism (which I consider
very important) for adapting the amount of work done while polling
to the available CPU cycles, so that the system is never unresponsive.
This one I could not replicate in -current (i.e. the same code that
works on stable does not work in current).
From a very useful discussion with Bruce Evans on the -net list
(if i got the details right), I think this has to do with kernel
threads not being preemptable, and hard/soft interrupt handlers
being kernel threads. On -stable, an interrupt handler can be
preempted by a higher priority interrupt.
This difference might require a sligthly different design of
the code. But I have also heard rumors on kernel threads possibly
becoming preemptable, which would fix at least one of my problems.
So, given that the code for -CURRENT is an entirely different beast,
needs some work which depends on how -CURRENT threads evolve, and
that 5.0-R is way ahead in time, I think it is more reasonable
to put that in when it is ready rather than commit some placeholder
code now and have a harder time in backing it out later when the
change might become buried in a bunch of other commits.
I tried to explain the above, at least the first two paragraphs,
in my emails to -core.
Let me also say that I have a hard time following the logic below:
> : Needless to say, I have some objection to this work going into -STABLE
> : before -CURRENT; do you have a schedule for completing the merge into
> : -CURRENT so this work isn't lost when we get to 5.0-RELEASE?
> I too have grave concerns about this. Can you please enlighten us as
> to your schedule? I'd hate to loose such a feature when we release
> 5.0-RELEASE.
so would you rather not have this feature at all than risk of losing
it in one year's time on 5.0-R ? If I had not committed this code
now (or soon) it would have been lost for STABLE as well, because
the time (and testing resources) I have to work on this project will
be largely reduced in a week's time.
Also it should not surprise you that CURRENT and STABLE are two
different beasts and what works (be it code or software architecture)
on one might not work as well on the other. Same for i386 vs alpha,
uniprocessor vs. SMP. Of course we all try to provide solutions
that work across the board from the beginning, but when this is
not possible it is IMHO a blind policy to set priorities that do
not match reality.
cheers
luigi
> Thanks much
>
> Warner
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe cvs-all" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011205085557.B63639>