On 05-Mar-02 Matthew Dillon wrote:
>:>     It makes no sense whatsoever to me to be told not to commit something
>:>     due to stale code that may not be quite compatible sitting in P4 that
>:>     you can't make work in any reasonable time frame.  You should stop
>:>     trying to screw over my work and instead look to your own.   You have
>:>     so many balls in the air constructed in a fine mesh that you can't seem
>:>     to accept a single change to your perfectly meshing subsystems, half
>:>     of which are going stale in P4.  This is greatly restricting your
>:>     ability to consider deviation.
>:*sigh*  The only reason I'm not spending my cycles tracking down the
>:bugs so that preemption can go in is that I have decided that at the moment
>:there is more gain to be found by doing actual locking work.  This means that
>:preemption will eventually go in, just Not Right Now.  To that extent, I
>:think premature optimizations based on observations of a kernel locked
>:by Giant that alter the API's preemption will change (and that were
>:introduced when I committed all the bits of the preemption code that I could
>:w/o breaking the kernel) should go in.
>     Those are your cycles, not mine.  Why should I be forced to sit on my
> heals
>     for an unknown period of time (but so far 3 weeks waiting for the ucred 
>     changes and 2 weeks waiting for critical_*()), twiddling my thumbs
> wasting
>     MY cycles just because of your own scheduling issues?
>     That's really the crux of this whole situation.  I don't think it is 
>     appropriate for you to impose your development methodology on me or
>     anyone else, and I most especially do not think it is appropriate for
>     you to arbitrarily hold off the hard work that I have done in order
>     to fit it into your schedule.  
>     I have said very clearly what I intend these critical_*() patches to
>     do.  I have said, repeatedly, that I do not believe they would 
>     intefere with your work in any significant manner.  You have yet to
>     explain in any detail why you think they would.  I have said,
>     repeatedly, that I am perfectly willing to work with you later on
>     when you ARE ready to move forward on your own work.
>     That's the crux of the situation, John.   I do not believe you have
>     the right to hold this work off, at least not based on any of the
>     explanations you have given so far.

Have you read the paper I posted to arch?  It quite clearly (I thought)
explained the role of the critical_* and the cpu_critical_* in the preemption
code.  It should be rather obvious from that why I don't want the critical_*
stuff to change from their current model.  I also think that just as it is too
early to optimize to light weight ithread switches (sparc64 is going to
optimize all kthread switches, not just ithreads by using a more general
approach, and we may do that on other arch's as well) it is too early to
optimize and add complexity for certain API's when we aren't sure what effect
they will really have on the final product.  For example, right now Giant
blocks almost all of the kernel so we are going to contest it on almost every
case.  Contesting involves grabbing the sched_lock which can result in
executing the critical section implementation more than we will end up doing
later.  I would rather wait on optimizations until the system is farther along
and we can judge what things really need optimization and which ones don't. 
Optimizations are usually a tradeoff as far as increased complexity vs.
performance and I personally at least would like to keep things simple for the
time being.  However, I would not be opposed to the code if it fit into the
design in the document I posted to arch.

A couple of notes though based on a quick preliminary glance at the code:

- The swi code has been changed to not be limited to a bitfield so that it can
  support an arbtirary number of swi's.  Right now we still support a small
  number but we may end up with several netisr's for example.  We also may move
  away from scheduling netisr's via swi_sched anyways and using a semaphore or
  some such instead.  Presently your patch goes back to assuming a fixed number
  of SWI's.
- More of a minor niglet that is easy to be fixed: you added MD fields to the MI
  pcpu bits of struct pcpu.  MD fields belong in the PCPU_MD_FIELDS macro in
  sys/i386/include/pcpu.h.  If you intend for the fields to be MI, then that is
  more of a problem as it assumes too much about interrupts for different
  platforms.  Alpha interrupts will not easily fit into a simple bitmask for


John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to