[openbeos] Re: Off-Topic: Con Kolivas quits Linux. He should know Haiku

On 8/10/07, Stephan Assmus <superstippi@xxxxxx> wrote:
> I don't mean to be pushy... but I'd *love* to see some code! :-)

*Rimshot!*

Message understood. Being taken care of. Over ;)

(Now, seriously: Real Life™ intervened and things went downhill at
work when I was away for a week. Expect actual code as soon as next
Monday.)

> I probably won't understand half of your eventual blog post, but I
> understand that our current scheduler has some problems that need fixing...
> ;-)

Of course you will. Have you checked the previous 5 entries? The
interesting ones for you would be the last 3, I guess.

> For example, a high priority thread can make the system *appear* to lock up
> completely. In fact, I have not had a true lockup of the app_server in
> months. Yet it seems like that can happen, while it is only some amok
> running menu or the like.

I can definitely see this happening if a high priority thread gets
stuck in an infinite loop. It's going to be preempted by the timer
interrupt, only to be immediately rescheduled if there are no higher
priority threads ready. If so, you should be able to continue using
the system if it's SMP.

But if this happens even on a SMP system, then the kernel becomes my
prime suspect. Can kernel code be executed simultaneously on more than
one CPU? Seems that even modern Unix recreations still suffer, in
varying severity, from this limitation.

> In fact, with our priority based threading, which
> is founded on the assumption that interactive threads get a high priority
> and non-interactive, number crunching threads get a low priority, I'd love
> if the scheduler would automatically unreal any high priority threads that
> suddenly consume a lot of CPU. Since the assumption is that this is not
> supposed to happen on our desktop tailored system.

I don't know if this is really necessary if the scheduler is fair and
proportional -- so the system won't lock up if some thread goes
runaway... unless it's inside a semaphore, but to prevent this we'll
need a way more sophisticated mechanism anyway --, but it's very
possible to implement aging if we find out we indeed need it.


Cheers,
A.

Other related posts: