On 29-May-2002 Seigo Tanimura wrote:
>>> And the p4 depot
>>>
>>> //depot/user/tanimura/ippreempt/...
>>>
>>> The patch is for only i386 at the moment.
>>>
>>> The following is the brief description of the patch:
>
> jhb> I would prefer that this was hung off the preemption stuff I've alread
On Wed, 29 May 2002 16:13:13 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
tanimura> Maybe we can solve both of the issues above by roughly checking if a
tanimura> thread can keep spinning without acquiring any locks, in the similar
tanimura> way as we do for a spin mutex. First, test the fo
On Tue, 28 May 2002 14:56:04 -0400 (EDT),
John Baldwin <[EMAIL PROTECTED]> said:
>> The prototype patch is at:
>>
>> http://people.FreeBSD.org/~tanimura/patches/ippreempt.diff.gz
>>
>> And the p4 depot
>>
>> //depot/user/tanimura/ippreempt/...
>>
>> The patch is for only i386 at the moment.
> The prototype patch is at:
>
> http://people.FreeBSD.org/~tanimura/patches/ippreempt.diff.gz
>
> And the p4 depot
>
> //depot/user/tanimura/ippreempt/...
>
> The patch is for only i386 at the moment.
>
> The following is the brief description of the patch:
I would prefer that this was hun
nter-processor interrupt to the processor chosen in 1.
>>
>> 3. The chosen processor puts its current thread back to the dispatch
>> queue and performs a context switch to run the new thread.
>>
>> Above is only a rough sketch. We have to watch out for a race of
>
o run the new thread.
>
> Above is only a rough sketch. We have to watch out for a race of
> inter-processor interrupts and a processor entering a critical section.
>
> If no one is working on preemption across processors, I would like to
> see if I can do that.
I actually think that
The chosen processor puts its current thread back to the dispatch
queue and performs a context switch to run the new thread.
Above is only a rough sketch. We have to watch out for a race of
inter-processor interrupts and a processor entering a critical section.
If no one is working on preempti
