Re: CpuSet on PAGG (Re: PAGG in Open Source projects?)

Kaigai Kohei <[email protected]>
Newsgroups gmane.linux.process-aggregates,gmane.linux.lse
Message-ID <[email protected]>
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 <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.