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 <kaigai@xxxxxxxxxxxxx>
|