atom feed28 messages in org.freebsd.freebsd-smpipending (was: SMP progress (was: Ste...
FromSent OnAttachments
Matthew DillonJun 23, 2000 11:36 am 
David GreenmanJun 24, 2000 9:10 pm 
Matthew DillonJun 25, 2000 10:24 am 
Jake BurkholderJun 25, 2000 11:19 am 
Chuck PatersonJun 26, 2000 9:50 am 
Matthew DillonJun 27, 2000 10:41 am 
Chuck PatersonJun 27, 2000 11:19 am 
Kevin Van MarenJun 29, 2000 1:52 pm 
Greg LeheyJul 2, 2000 6:51 pm 
Jason EvansJul 3, 2000 8:41 am 
Jake BurkholderJul 3, 2000 1:14 pm 
Jake BurkholderJul 5, 2000 2:23 am 
Matthew DillonJul 5, 2000 9:43 am 
Chuck PatersonJul 5, 2000 9:52 am 
Chuck PatersonJul 5, 2000 9:57 am 
Luoqi ChenJul 5, 2000 10:29 am 
Matthew DillonJul 5, 2000 11:28 am 
Greg LeheyJul 5, 2000 4:20 pm 
Doug RabsonJul 6, 2000 1:26 am 
Matthew DillonJul 6, 2000 10:43 am 
Greg LeheyJul 22, 2000 2:26 am 
Matthew DillonJul 22, 2000 9:20 am 
Chuck PatersonJul 22, 2000 9:57 am 
Bruce EvansJul 22, 2000 10:36 am 
Greg LeheyJul 23, 2000 8:14 pm 
Bruce EvansJul 24, 2000 1:08 am 
Chuck PatersonJul 24, 2000 6:43 am 
Matthew DillonJul 24, 2000 9:16 am 
Subject:ipending (was: SMP progress (was: Stepping on Toes))
From:Greg Lehey (gr@lemis.com)
Date:Jul 22, 2000 2:26:43 am
List:org.freebsd.freebsd-smp

On Wednesday, 5 July 2000 at 10:52:23 -0600, Chuck Paterson wrote:

Jake Burkholder is porting the BSD/OS mutexes. I don't expect there to be much of a difference in regards to your heavy-weight interrupt work. I'm going to take a look at Jake's patchset tonight. I think the only operational item we need to research is the sti/cli stuff in the BSDI mutexes... we should be able to remove them at some point (my interrupt code is already using the ipending mechanism to deal with the scheduler mutex being active on the current cpu).

If Jake's removed that, then we'll want to put it back in at some point since it saves a significant amount of overhead ('sti' and 'cli' are expensive instructions).

I believe ipending wants to go away totally. It really isn't meaningful in the thread environment and the locked operations needed to support it once multiple processor are running in the kernel are more expensive the sti, cli.

After working through the code, I agree. It's complicated to maintain, and it's not needed. Removing it also has helped me find a number of places where I need to change things.

In a similar way, I'm removing interrupt mask copies in memory. We still mask interrupts which aren't in use, but no others. If anybody has any reason not to want to do this, we should talk about it.

Greg

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message