Date: Wed, 6 Mar 2002 15:16:40 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> 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: <200203062316.g26NGeF59131@apollo.backplane.com> References: <XFMail.020306174319.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
tell.
: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 <jhb@FreeBSD.org> <>< 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.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200203062316.g26NGeF59131>