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

Eric Keller wrote:
> Thanks for the reply. More below.
>
>
>>> What I'm trying to do is to run a kernel thread, but have it associated
>>> with a particular user's context. The reason is this - I want to run
>>> Click in the kernel, but allow each user to provide their own click
>>> graph. The root context will manage the whole process, performing
>>> checks, then merging the various click graphs into a single click
>>> graph,
>>> and installing that in the kernel. Each user graph would be run within
>>> their own kernel thread.
>>>
>>
>> Why would it need to be associated with the context? How would it be
>> started?
>>
> There is a single kernel module that gets installed with insmod, it
> starts up N kernel threads (one for each user context). I do this in
> the root context. The user gets to partially define the functionality
> of the thread, so I want the CPU cycles, etc, to be charged to that
> context (so they are still limited to what the configuration of vserver
> specifies).

So what is creating the kernel thread when a context is created?

Note that running a kernel thread in a context requires you to make sure
it exits when the context is supposed to die, or make it possible to kill
it. I'm not sure what sort of life-span we're talking about.

>>> I've looked through the vserver code and before I start doing any
>>> modifications, I wanted to post to the group to see if anyone has any
>>> guidance. It appears that include/linux/vs_context.h provides all of
>>> the functionality I'd need. So I would start the kernel thread as
>>> usual, then I would transfer it (by changing vx_info and xid, from
>>> task_struct) from the kernel's vx_info to a particular user context's
>>> vx_info (I would get the vx_info with lookup_vx_info(xid)).
>>>
>>
>> All those values are inherited from the parent, so this kind of depends
>> on
>> the answer to my second question above.
>>
>> 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.

Seems like it.

-- 
Daniel Hokka Zakrisson