: :> Right now the SP build works because I am allowing (unthreaded)
interrupts :> to steal the idleproc's context, and that only works because they can :> get the giant mutex without blocking (remember, the BSDI giant mutex :> is a blocking mutex, not a spin mutex). In the MP build the interrupts :> need to be able to block getting the giant mutex which means we need :> to implement heavy-weight interrupt threads at the very least before :> we can get anything working, because we are not allowed to block in :> the idleproc. :> :May I suggest we first make the giant mutex a spin mutex (as our good old :giant kernel lock) and focus on the SP first? In the mean time, MP should :continue to work, as only one processor is allowed in the kernel. Once the :SP is stablized, we start to tackle the MP build. : :-lq

Without interrupt threads it doesn't matter whether the GiantMutex is a spin or a blocking mutex because it will never get that far... it will always succeed the first try in the SP build.

But we have to implement interrupt threads in order to be able to migrate away from the SPL mechanism, and we have to do that for both builds (rip SPL's out of the kernel entirely). This, in fact, represents *most* of the work that is going to occur in the next few months (ripping out SPL's and replacing them with Mutexes).

The whole thing is interrelated. The GiantMutex must be held in order to be able to use the 'old' SPL mechanisms during the transition period. Interrupts must be threaded in order to be able to start replacing SPL's with mutexes. GiantMutex must be a blocking mutex to be able to thread interrupts. Therefore the GiantMutex must be a blocking mutex.

Interrupt threads are going to be 'in' in less then a week. To delay it would delay the entire project for the reasons outlined in the previous paragraph.

The Schedular mutex is a spinning lock in the new design and replaces the scheduler-aspects that the *old* spinning MP lock handled before. However, the aspects of the old MP lock that protected entry into the kernel (verses just the scheduler), migrates to the new blocking GiantMutex.

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