From: Paul J. <pj...@sg...> - 2005-02-01 16:13:45
|
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...@sg...> 1.650.933.1373, 1.925.600.0401 |