cvs commit: src/sys/alpha/conf GENERIC src/sys/amd64/confGENERIC src/sys/sparc64/conf GENERIC

[Julian Elischer]

Jeff Roberson wrote:
> On Wed, 8 Sep 2004, Scott Long wrote:
> 
> 
>>Jeff Roberson wrote:
>>
>>>What's not working well enough with ULE to run with it?
>>>
>>
>>The package build machines were switched over to 4BSD not long ago and
>>have since been reported to be more stable.  I can also lock up or panic
>>my test machine within seconds with ULE, especially if preemption is
>>enabled.  This was the case both before and after Julian's scheduler
>>cleanup change went in, also.
> 
> 
> I wasn't aware there were any more panics after julian's preemption
> change.  Are there any problems without preemption?  What causes the panic
> with preemption?

There appear to be two problems.
One that is still related to preemption and
one that is not.

the preemption problem is hard to describe, but seems to result in either a
null reference of some kind (last I looked) and the one that is not driven
by preemption finds that a kse is already in a run queue and panics..

The preemption one seems to be with KSE threads still but may not
always be so.

 From your perspective the changes to ULE that I have made are:
* Every thread always has a kse, and it is the same thing as the td_sched
structure.

* Concurrency/fairness (slightly overloaded but that may change some time)
is no longer done with the number of KSEs avaliable but rather,
with a plain counter of "threads on teh run queue or running" in the ksegrp.
Some fields in the kse have moved into teh kg_sched struct.
(with macros keeping the old name.

* In addition.. setrunqueue has grown a flag argument that can say where
we were called from so that the "preemptive" flag you have can be generated.
The flag values are not set in concrete yet.

Given these changes it would be a real help if you looked through the combined
sched_ule.c/kern_switch.c to see if they or preemption is breaking any of your
assumptions, published or otherwise.

> 
> 
>>Scott
>>