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 <pj@xxxxxxx> 1.650.933.1373, 1.925.600.0401
|