Re: panic: APIC: Previous IPI is stuck

Matthew Dillon wrote:

>:Scott Long wrote:
>:
>:> The 'fix the bugs' discussions are going on too.  However, this is the
>:> freebsd-current list, and it's always nice to discuss things that might
>:> be suitable further down the road.
>:
>:Yes, I might have gotten this wrong, I thought he was talking 
>:specifically about 5.x (which to me, and I guess many other users, means 
>:the long awaited stabilization of the 5.x tree).
>:
>:-- 
>:   Matthias Buelow; mkb_at_{mukappabeta,informatik.uni-wuerzburg}.de
>
>    I am using "-current" and "5.x" interchangably, since there isn't really
>    much of a distinction between the two, at least not from my point of
>    view. 
>
>    As far as stabilization goes... well, the problem is that you can only 
>    stabilize what you have once you have it.  The APIs, abstractions, and
>    requirements are so complex in -current/5.x that every time someone
>    codes up something new, major bugs are introduced.  Even worse, many of
>    the bugs introduced are difficult to reproduce, track down, and fix.  Of
>    course, new bugs are introduced occurs with any OS development... DragonFly
>    is no exception.  But there are 'normal occurances' of such things, and 
>    then you have the 'its so fragging complex that I couldn't code it right
>    the first time if I tried!'.  -current/5.x is definitely in the latter
>    category.
>
>    The question you have to ask yourself is:  Do you want to spend all your
>    time tracking down all the bugs that are constantly being introduced into
>    the codebase, or do you want to simplify your APIs and abstractions to
>    *reduce* the instances of new bugs being introduced so you can spend more
>    of your time implementing neat new things instead?
>


I certianly agree about a lot of this and I'm as guilty as the rest of 
adding stuff.
(I'm now trying to clean some of it up but it's hard after other people 
entwine your
 own mistakes into their code. :-)

The IPI code is a very likely candidate for merging sooner than later.
I tried to add code to allow setrunnable (and friends) to immediatly 
kick an idle thread (in hlt)
to come and get the newly scheduled thread but it wasn't to easy as teh 
IPI code was not
all that general.

I haven't looked at Matthew's IPI code (nor ours), since it was written 
but at that time it
seemed to be a pretty straight forward  'drop in' replacement. (not too 
surprising really).

Who IS "Mr IPI"?  That's the problem with the system at teh moment... 
you have to know who
"Mr  ${module}" is for any given "Module" because there is such a high 
level of domain knwledge
needed for each subsystem. 

I'm presuming it's jhb with assistance from peter, but I'm not sure..
It's be nice to know what is required to "drop in" teh new IPI code. 
Then I could retry adding teh code
to kickstart idle cpus when work becomes available instead of waiting 
for the next tick for them to notice..

Drew recently saw a 10-20% increase in throughput by going to not using 
'hlt" in idle CPUs
on a threaded application.
(which itself slows down some things so the real improvement might have 
been more)
So there is really some gain to be had.

It''s been in DF for a year now so it's not "untried" code.

>
>    Another question you have to ask yourself is:  If you have a kernel whos
>    APIs and abstractions are so complex that even veteran kernel hackers
>    are having to test in perforce for weeks, months, or even longer before
>    daring to bring the code into CVS, and even then wind up with serious bugs,
>    what do you think the situation is going to be for all the other developers
>    out there trying to work on the FreeBSD kernel?
>
>    I'm not going to repeat all the suggestions I've made in the past.  It is
>    obvious to me that FreeBSD development needs to stop *right* *now*, take
>    a step back, and figure out how to simplify the MP requirements for
>    all the major subsystems... then spend 3 months doing it.  IPIs are a good
>    example... it needs a complete rewrite.  The scheduler pretty much needs
>    a complete rewrite.  The memory subsystem is in pretty good shape but
>    would work even better using a DragonFly style cpu localization model.
>    The interrupt subsystem... well, again, you need DFly style preemption
>    instead of heavy-weight-scheduler-integrated-with-priority-borrowing-
>    preemptive-thread-switching-and-preemptive-cpu-migrative-and-oh-yah-don't-
>    forget-to-pin-the-cpu-because-if-you-do-we-will-never-find-the-bugs-
>    you-introduce-otherwise style preemption.
>
>						-Matt
>
>_______________________________________________
>freebsd-current_at_freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>  
>