Date: Sun, 18 Mar 2001 08:01:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: imp@harmony.village.org (Warner Losh) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), jhb@FreeBSD.ORG (John Baldwin), mjacob@feral.com (Matthew Jacob), arch@FreeBSD.ORG Subject: Re: man pages Message-ID: <200103180801.BAA03653@usr05.primenet.com> In-Reply-To: <200103171820.f2HIKq945996@harmony.village.org> from "Warner Losh" at Mar 17, 2001 11:20:52 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> : >Just wanted to show > : >an example that needed it, not for synchronization, but to assume total > : >control of the CPU and to make everyone else wait while I do my > : >semi-time critical hardware frobbing. > : > : I agree, there are lots of applications where it is a must to be > : able to do that, and we can either provide a civilized API for it > : or suffer all the weird hacks people will implement themselves... > > My hardware was UP. I don't know what I'd want this to mean in an MP > environment. For my app, one CPU is fine (since the bus bandwidth I > use in my handsprings is minimal). This likely is the typical case. > > I have trouble thinking of why someone would want to do this on > multiple CPUs at the same time, unless it involved synchronization. My immediate question on the original "Just wanted to show..." posting was "What about SMP?". I think that there are several types of critical sections: 1) Keep this CPU from fielding interrupts 2) Keep this CPU from having to run other code (kernel preemption safe) 3) Keep the I/O bus from being used by other code, since I'm engaged in time critical work I think what you want to do is lock off interrupts from the CPU, and then lock other code out of the I/O bus until you are done programming the DMA. Given the original example code, and the anecdotal statement that "disabling interrupts worked better", I'd have to say my best guess is that your code really needed to be able to lock access to the I/O bus, as well as preventing the CPU from being forced to run other interrupt handling code (cases #1 and #2 are similar, but distinct, in that way). Setting aside the idea that you should perhaps preprogram the DMA engine as best you can ahead of time, to avoid it being nearly as time critical (during init, and again, after each interrupt handler has effective run to completion), I think this calls for _at least_ a way to disable interrupt sources seperately from CPU interrupts, and possibly a seperate method of monopolizing the I/O bus. I think if you could disable sources (on some architectures, you would have to disable all sinks, instead, just as on some, you can only disable sources, and disabling them for one CPU disables them for all), then it would make your driver work in SMP mode; so would disabling interrupts to the sink (CPU) you are currently running on plus locking access to the I/O bus against other CPUs. You could actually envision a third routine which does a "don't interrupt this CPU, and grant it monopoly I/O bus access" that uses one method on some architectures, and another method on others. PS: Is there a reason we shouldn't just adopt Sun's function names and semantics? They've paid people to look at this for a long time. I personally don't have a problem with benefitting from thousands of amn hours and millions of dollars of architecture work by professional computer scientists, at no cost... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103180801.BAA03653>