From: Kaigai K. <ka...@ak...> - 2005-02-03 13:45:03
|
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 <ka...@ak...> |