Hello, Paul.
Thank you for your fast and attentive response.
Excuse me for less explanation.
I wondered why every advanced feature duplicates its own hooks
in fork()/exit() for those event handling.
Thus, my main motivation and attention are about fork()/exit() event handling.
Because of this, I didn't intend to implement all of the CpuSet without
a specific patch.
About PAGG implementation:
>> (CpuSet-patch needs lockless references.)
>
>
> I am a little surprised that the fork/exit cpuset hooks must
> be lockless.
I'm not talking about another CpuSet patch.
When CpuSet patch is on PAGG as I modified, CpuSet functionality
need refer a PAGG object related to CpuSet in some points.
pagg_get() require that caller must hold pagg_sem semaphore,
though we can't hold a semaphore from an interruption context or
a critical section wedged between spinlock().
Thus, CpuSet-patch needs lockless references (to PAGG object).
__alloc_pages() has possibility to be called from a section which
cannot block. Thus, I replaced PAGG semaphore by RCU.
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.
> Aside -- if you do value cpusets, please put in a good word for them
> with Andrew Morton, on lkml perhaps. He will _not_ further the advance
> of cpusets unless others outside SGI ask for them eagerly.
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.
Thanks.
--
Linux Promotion Center, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
|