: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_*

    I'm sorry John, I have no idea what you are refering to here.  You have
    given no reference that I can lookup... you have hundreds of postings 
    on arch.  

    Why don't you just post the reasoning?  Nothing I have seen anywhere
    so far would create an issue.  I've heard you repeatedly reference
    documents but I have no idea which documents you are talking about
    or which portion of said documents you are refering to.  So instead
    of continuing to post ghost references why don't you just lay the
    problem out as you see it in this thread and explain why you do not
    believe the critical section work I am doing would work with it.

: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

    We have very different development models, and different priorities.
    I'm not sure why you are attempting to impose your development model
    and priorities on me.  This is the work I want to do.  It's my time
    here, not yours, and if you believe that the work will make your job
    harder in some future unspecified commit then you have only to bring
    up the issue down the road when you are actually ready to work on
    that future unspecified commit and we can work it out.  But I don't
    think it's appropriate for you to impose such a strict set of requirements
    based on work that does not exist in -current anywhere as far as I can

: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. 

    Again, different development models.  I see a set of APIs being severely
    misused by commits, the most recent being Peter's-that-he-backed-out,
    and I see a considerable need down the road for an efficient critical
    section API.  You may not be interested in doing the work on these now
    but you != me.  This work is my interest.  Again, I don't understand why
    you are trying to impose your personal tastes on me.

: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.

    I see an swi scheduler, which has nothing to do with the critical section
    work I have done.  If there is other SWI stuff I don't see it in the
    -current tree.  Nor does the work I have done in any way prevent the
    use of or in any way make it more difficult to use a list-based SWI
    queueing system instead of a bitmap. 

    The bitmap stuff in my critical section patch only applies to i386... it's
    a specific implementation for soft and statclock IPI forwarding for
    the deferred case, nothing more.  I didn't even bother to integrate AST
    (saving that for later work).  It does not in any way prevent one
    from redoing that bit of code or even simply keeping the code and adding
    an SWI queue feature - something that could in fact be done either MD or
    MI depending on the needs of the architectures.

    If you believe there to be a problem here, perhaps explaining the SWI
    mechanism you are refering to would help.  I am confident that it would
    not impose anything incompatible with the work I've done.

:- 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
:  example.
:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/

    These fields do in fact belong in MD PCPU_MD_FIELDS.  I didn't notice
    it, perhaps because there is not a single line of comment in
    sys/pcpu.h explaining what PCPU_MD_FIELDS was.  There is in the
    i386 specific pcpu.h, but not in the main sys/pcpu.h header file and
    there should have been.

    This is about a 10 second change.  I don't consider it all that
    significant and I will be happy to do it in the stage-2 commit.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

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

Reply via email to