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

Kaigai wrote:
> Hello, Paul.
> Thank you for your fast and attentive response.

Thank-you for starting this good discussion.


> Excuse me for less explanation.

No problem.  Please excuse my many questions.


> 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.


> I'm not talking about another CpuSet patch.

Good - I was just checking.  Thanks.


> 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.

Are you saying that pagg_sem can't block?  I thought semaphores
could block.

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)?


>  > 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.

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.

Thank-you.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <[email protected]> 1.650.933.1373, 1.925.600.0401