[Lse-tech] Re: CpuSet on PAGG (Re: PAGG in Open Source projects?)

[Kaigai K. <ka...@ak...>]

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 <ka...@ak...>