Re: Will kernel thread run out of time slice?

["Min-Hua Chen" <orca.chen@xxxxxxxxx>]

hi

On 4/24/06, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:

Hi...

> I don't  know how to  "CC to kernelnewbies", how?

Easy. If you use mail user agent such KMail, you will a field named CC
or BCC. Just put kernelnewbies@xxxxxxxxxxxx there. Same thing to do if
you reply it using web interface such as GMail's.

ok,  I've got it.

> I have no idea about that, and I have to use linux-2.4.18 bacause
> that can be
> port to ARM, if we use linux-2.6.x, it will takes us a lot of time to
> do porting.

Ok, I understand.

> > What? "loop" goes to 25 and then goes back to 20? How come? BTW,
> > how many kernel thread did you make? 1? 2? More? Can you paste your
> > entire code please? This guessing game isn't effective at all.
>
> thread 11's loop 25 and thread 10's loop 24, that's what I want.
> both threads are trying to print 1,2,...,1000 and when thread 11 ran
> out of time slice, kernel switch to thread 10. You can see thread 11
> ran out of time
> slice and thread get a new time slice (6 ticks)

OK, so let me conclude, you made two kernel thread (or more?) and each
of them are executing dummy_loop()?

And another thing.... why do you think your output is not correct? Do
you want something like this?
thread 1 loop 1...
thread 2 loop 1
thread 1 loop 2...
thread 2 loop 2..

In that case, you can't rely just with involuntary kernel level
preemption. The reason is: involuntary preemption happens when time
slice expired or another task with higher priority is awaken and
scheduled. So, to keep with the above pattern, put schedule() in the
end of each iteration:
for()
{
        ...
        ...
        schedule()
}

But in the other hand, if what you want is kernel thread A to finish 1st
and then kernel thread B, then what you need is disabling preemption.
Usually you use preempt_disable() to do it, but you said spin lock
grabbing does the trick too. I think it works too because implicitly,
grabbing spin lock also disable preemption.

Does this clear up the issue for you?

The kernel is preemptive and context did happen, right?
why the same code (without spin lock/preempt_disable())
works fine by pthread API and looks strange when in the kernel.

 

regards

Mulyadi

regards,
Min-Hua