Re: CpuSet on PAGG (Re: PAGG in Open Source projects?)

Hi, Erik. Thanks for your comments.

Erik Jacobson wrote:
 >>I agree that Call-by-string-name dynamically evaluated invocations are
 >>expensive and not good as you said.
 >>(1) It should be possible to refer a PAGG object from some critical
 >>sections. (2) It should be light-weight to refer a PAGG object for
 >>each customer. IMO, these should be fixed for PAGG to be widely-supported.
 >>I want a comment by Erik Jacobson.
 >
 >
 > Sorry for the delay.  I was on vacation.
 >
 > For (1) - can you give some examples?

For example, I want to refer the PAGG object for each task
when we scan the task-list under the read_lock(&tasklist_lock).
Using semaphore for exclusion isn't appropriate st such times.

And, we should avoid to use any kind of spinlock as possible as we can,
because it's expencive.
I think RCU is appropriate for alternative lockless method in this case.
# RCU's bad point is current PAGG's custmer must be forced to modify
# own implementation.

 > For (2) - If you look at the exec hook __pagg_exec function, we go through
 > the list of paggs for the task that reached the hook, and we execute the
 > associated function pointer (if it is assigned in the pagg hook).  When we
 > execute the associated exec function pointer, we pass a reference to the pagg
 > in question.

It's right when we are processing the hook function.
But we can call pagg_get() to refer the PAGG object in other place.

I think the issue of (2) is using string comparison in pagg_get and so on.
Generically, string comparison is more expensive than integer one.

Is it possible that PAGG-engine associates the unique integer key with
PAGG's customer(such as Job) when pagg_hook_register() was called, and
we can call pagg_get() with task_strcut and this integer key instead of
PAGG-custmer's identical string(such as "job" or "cpuset") ?

 > pagg_get I suppose is a tiny bit expensive but it only gets bad when there
 > are lots of pagg associations for a given task.  I assume this is your
 > concern for (2) though, right?

That's right also, I think. But is it unavoidable ?

 > If we were to change this, what would you suggest?  Recall that there is
 > a data pointer in the pagg structure that kernel module "customers" can
 > store stuff in on a per-task basis.  One could envision look-up tables
 > or something, but that seems only a little less expensive and more
 > complicated.

My proposal is that pagg_sem should be replaced by RCU for issue (1).

For example, is it possible to abolish strcmp() for the issue (2)
by the following method ?

1) pagg_hook_register() returns the unique integer key associated with
    PAGG's customer registered.
2) That unique integer key is made a key for finding the PAGG object.

   struct pagg * pagg_get(struct task_struct *task, int key){
     struct pagg *pagg;
     list_for_each_entry(pagg, &task->pagg_list, entry) {
     if (key==pagg->key)
       return pagg;
     return NULL;
   }

I expect that PAGG and PAGG's custmer such as Job is merged into up-stream kernel.
Thanks.
-- 
Linux Promotion Center, NEC
KaiGai Kohei <[email protected]>