Re: [vserver] Kernel Thread's accounted to a User Context

Eric Keller wrote:
>>>> Note that there are more values to consider. vx_migrate_task handles
>>>> all
>>>> this for you, so you might want to look at using that...
>>>>
>>>>
>>> Thanks, I think vx_migrate_task may indeed be what I'm looking for.
>>> Based on what I responded above, do you agree? The kernel thread would
>>> start under the root context, then I would get the vx_info of the user
>>> context that I'm interested in, then call vx_migrate_task and I should
>>> be set.
>>>
>>
>>
>
> I used vx_migrate_task and I see signs that it worked. Basically my
> program starts N threads, then migrates one of the threads to context
> 777, then that thread basically does a lot of work in a loop. Here is
> what makes me think it worked:
>
> 1) I print out the address of task->vx_info before migration and then
> immediate after, it was null before and non-null after. Inside of the
> thread, I periodically print out the address of its vx_info, and it is
> the non-null one I saw previously.
>
> 2) Inside of the context I run top. Before I run the program I see 4
> tasks, after I run the program I see 5 (If I run my program without
> migrating, then I don't see the increase in tasks). Top also shows the
> percentage system time as going up.
>
> 3) from root context doing 'more /proc/virtual/777/sched' several times
> in a row shows that the system ticks are increasing and the tokens stay
> close or at 0.
>
> So that makes me think it works, but despite using hard cpu scheduling,
> my kernel thread seems to be unconstrained. I can get it to any
> percentage of the CPU that I want. Inside of the context if I run a
> program that basically does an infinite loop, it gets up to the
> percentage usage I would expect based on how I set the fill-rate and
> interval (I tried both a 1/4 and a 2/40 fill-rate/interval settings). I
> also notice that that percentage the user program gets doesn't change
> whether I have my kernel thread running or not.
>
> Do you have any more guidance for me - where to look, things to try,
> what to print out, etc.?

This was something we discussed briefly at a VINI-meeting some time
earlier this week (or was it last week?). If you want to consume tokens in
kernel space, you'll probably have to call one of the functions in
kernel/sched_hard.h.

Now, for kernel threads, that shouldn't be necessary. I can see a
potential bug in the kernel here, but I'd have to verify that. What kernel
are you working with?

> Thanks,
> Eric
>

-- 
Daniel Hokka Zakrisson