Hello, Paul.
Thanks for your comments.
>>I wondered why every advanced feature duplicates its own hooks
>>in fork()/exit() for those event handling.
>
>
> Sometimes the simple mechanism is the best. If dozens of features
> require a special subroutine to be called from the same place, such as
> fork, exec or init (kernel boot), then perhaps dozens of subroutine
> calls, all in a row, is best.
>
> Just because a way of doing things requires a minimum of compute cycles,
> and is so simple that even a beginning programmer can understand it
> almost immediately, doesn't make it inferior.
Hmm..., 'Simple is the best' is truth, I also think.
>>__alloc_pages() has possibility to be called from a section which
>>cannot block. Thus, I replaced PAGG semaphore by RCU.
>
> Are you saying that pagg_sem can't block? I thought semaphores
> could block.
No, semaphores always have possibility to block, and pagg_sem is also same.
(Who dose need a never-blocking-semaphore?)
When I modified the CpuSet feature for using PAGG, I noticed we need call
pagg_get() from some critical sections.
Thus, I modified PAGG to replace task->pagg_sem by RCU.
pagg_get() does not block on the PAGG implemented by RCU.
> I am missing something here. What is the sequence of events that
> would lead to trying to hold a semaphore from interrupt context
> (before your lockless changes)?
For example, pid_array_load() in kernel/cpuset.c is relevant.
(This is the Paul Jackson's original implementation.)
int pid_array_load()
{
read_lock(&tasklist_lock); ---------
do_each_thread(g, p) { ^
if (p->cpuset == cs) { |
: Critical
} Section
} while_each_thread(g, p); |
array_full: v
read_unlock(&tasklist_lock); ---------
}
In this case, if CpuSet would be a PAGG's custmer, we call pagg_call()
to refer the PAGG object related to each task under the
read_lock(&tasklist_lock).
Thus, pagg_get() must not block.
>>Indeed, I think CpuSet and PAGG(+Job/CSA) are so worthwhile solution.
>>I'll try to move the discussion into LKML.
>>But we might start from the improvement of PAGG before it.
>
> I think that there is a good chance that later this month, February 2005,
> the subject of the cpuset patch will again become active on lkml.
> I will be pleased and grateful for any support you might provide to
> encourage the acceptance of cpusets.
Today, my colleague acclaim CpuSet also. :)
It's good, if we can use CpuSet on stock-kernel.
Thank you.
--
Linux Promotion Center, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
|