Re: splFoo() question
On Tuesday, 21 March 2000 at 7:46:57 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Wes Peters writes: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Warner Losh writes: I'd like to be able to do some simple spl locking in a driver that I'm writing. While I could go the splhigh() route, I'm concerned that spending lots of time at splhigh could cause problems, and some of my critical sections look to be very expensive. They only need protection against the card itself, not against the entire system. It just seems to be an overly large hammer. I miss this too. Semaphores? spl*() are semaphores. spl*() are interrupt lockouts. The difference is very evident in an SMP environment. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
Wes Peters wrote: A per-driver mutex, perhaps? This would save us from potential deadly embraces within a single driver, at least. I'm surprised no one mentioned the following yet. splFoo() is one of FreeBSD curses. While what we have is much better than the older splFoo() stuff, it's still pretty much the giant kernel lock thingy. We need to get away from that of many reasons. Well, one of the reasons is better SMP. Alas, BSD/OS allegedly have a kick-ass SMP, which means they have replaced the splFoo() ickyness. It would be useful to know if we'll be, indeed, using an alternative they have developed, or if we are going to roll our own. Now, there are TONS of research in OS concerning this. As a matter of fact, we could even copy what _Linux_ is using to solve the problem. This is not the place for NIH attacks. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
In message [EMAIL PROTECTED], Warner Losh writes: I'd like to be able to do some simple spl locking in a driver that I'm writing. While I could go the splhigh() route, I'm concerned that spending lots of time at splhigh could cause problems, and some of my critical sections look to be very expensive. They only need protection against the card itself, not against the entire system. It just seems to be an overly large hammer. I miss this too. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
On Sat, Mar 18, 2000 at 01:31:28PM -0700, Warner Losh wrote: I'd like to be able to do some simple spl locking in a driver that I'm writing. While I could go the splhigh() route, I'm concerned that spending lots of time at splhigh could cause problems, and some of my critical sections look to be very expensive. They only need protection against the card itself, not against the entire system. It just seems to be an overly large hammer. perhaps we need some mutex mechanism? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
In message [EMAIL PROTECTED] Guido van Rooij writes: : perhaps we need some mutex mechanism? Yes. Right now the mutex mechanism that we have is blocking of interrupts when the bit is set in the cpl. I guess I'm a little too close to the mechanism and need to step back. You are right that I'm asking for a call that is approximately "block my interrupt handler from running until I say it is ok." A more generalized mutex/locking scheme is needed so that I can just grab a mutex in my code and in my ISR and the right thing will just happen. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
: perhaps we need some mutex mechanism? Yes. Right now the mutex mechanism that we have is blocking of interrupts when the bit is set in the cpl. I guess I'm a little too close to the mechanism and need to step back. You are right that I'm asking for a call that is approximately "block my interrupt handler from running until I say it is ok." A more generalized mutex/locking scheme is needed so that I can just grab a mutex in my code and in my ISR and the right thing will just happen. A per-driver mutex, perhaps? This would save us from potential deadly embraces within a single driver, at least. The only concern I can see is that currently it requires you to get too cozy with the machine independant code. Basically, the 'resource' that you want to lock on is the IRQ, and the raw IRQ code is quite machine dependant. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
Warner Losh wrote: In message [EMAIL PROTECTED] Guido van Rooij writes: : perhaps we need some mutex mechanism? Yes. Right now the mutex mechanism that we have is blocking of interrupts when the bit is set in the cpl. I guess I'm a little too close to the mechanism and need to step back. You are right that I'm asking for a call that is approximately "block my interrupt handler from running until I say it is ok." A more generalized mutex/locking scheme is needed so that I can just grab a mutex in my code and in my ISR and the right thing will just happen. A per-driver mutex, perhaps? This would save us from potential deadly embraces within a single driver, at least. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
In message [EMAIL PROTECTED], Wes Peters writes: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Warner Losh writes: I'd like to be able to do some simple spl locking in a driver that I'm writing. While I could go the splhigh() route, I'm concerned that spending lots of time at splhigh could cause problems, and some of my critical sections look to be very expensive. They only need protection against the card itself, not against the entire system. It just seems to be an overly large hammer. I miss this too. Semaphores? spl*() are semaphores. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : In message [EMAIL PROTECTED] Guido van Rooij writes: : : perhaps we need some mutex mechanism? : : Yes. Right now the mutex mechanism that we have is blocking of : interrupts when the bit is set in the cpl. I guess I'm a little too : close to the mechanism and need to step back. : : You are right that I'm asking for a call that is approximately "block : my interrupt handler from running until I say it is ok." A more : generalized mutex/locking scheme is needed so that I can just grab a : mutex in my code and in my ISR and the right thing will just happen. : : A per-driver mutex, perhaps? This would save us from potential : deadly embraces within a single driver, at least. We kinda sorta have this right now with the interrupt routine being blocked when the cpl is too high. I'd like to see this more generalized than it is today. However, jumping in and mucking with this code makes me nervous. I'm much more familiar with VxWorks style device drivers, which typically just give a "go" semaphore to an appropriate task that will then perform the actual I/O in a task (think thread) context. It's a different kind of beast from a typical UNIX driver model, but it goes a long way towards avoiding interrupt livelock, since you can balance the priorities of the threads doing the actual I/O. This seems like a good place to point out how much kernel threads would help. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
Shouldn't all of this should be properties of the newbus code? There should be
some value that is associated with any device that says "I need to disable
receiving interrupts from this device". This could then fold into an MP
spinlock case that honors device interrupts. What you're describing below *is*
machine dependent, but very similar to the ddi_iblock_cookie_t for Solaris,
which also then had the related ddi_idevice_cookie_t (which would have the
bits appropriate for programming 'programmable' interrupt levels)- but
considering it 'newbus' dependent is certainly better sounding than "machine
dependent".
I'm eager to hear if there's a way already to do this in FreeBSD.
On Sat, 18 Mar 2000, Warner Losh wrote:
I'd like to be able to do some simple spl locking in a driver that I'm
writing. While I could go the splhigh() route, I'm concerned that
spending lots of time at splhigh could cause problems, and some of my
critical sections look to be very expensive. They only need
protection against the card itself, not against the entire system. It
just seems to be an overly large hammer.
In addition to the driver I'm working on now, I've watned to do this
in the pccard system so that we block interrupts for the cards when
we're mucking around with the pccard bridge chipset on eject events.
Right now, I'm using splhigh() for that, but that strikes me as
excessive.
I've wanted to do something like this for a long time, so I thought
I'd spend some time diving down into the spl code and digging around.
Always a dangerous thing to do, I know.
My first thought was to use splx, but that's for lowering the spl (eg
clearing bits) rather than raising it.
So instead, I'd like to have a code that looks like:
s = splirq(n);
...
splx(s);
in my code.
A nieve implementation would be
static __inline int splirq(int n)
{
int oldcpl;
oldcpl = cpl;
cpl |= (1 n);
return oldcpl;
}
This strikes me rather dangerous, machine dependent, and making unwise
assumptions. It wouldn't work on MP. I'm sure that there are lots of
other reasons that this won't work which aren't immediately obvious...
Except for shift vs mask differences, this looks identical to the splq
code in the UP case. I also notice that splq doesn't appear in the
spl(9) man page and thus might disappear in the future. I further
notice that it appears to be a i386 only routine, appearing only in:
i386/include/lock.h
i386/isa/intr_machdep.c
i386/isa/intr_machdep.h
i386/isa/ipl_funcs.c
There's got to be a simple, MI way to do things like this, but I'm not
sure that I'm seeing any.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
