From kaigai@ak.jp.nec.com Tue Feb 1 05:06:23 2005 Received: with ECARTIS (v1.0.0; list pagg); Tue, 01 Feb 2005 05:06:30 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11D6M5T028890 for ; Tue, 1 Feb 2005 05:06:22 -0800 Received: from mailgate4.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j11D56e17348; Tue, 1 Feb 2005 22:05:06 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j11D55E09422; Tue, 1 Feb 2005 22:05:05 +0900 (JST) Received: from mailsv.bs1.fc.nec.co.jp (venus.hpc.bs1.fc.nec.co.jp [10.34.77.164]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id j11D55t19320; Tue, 1 Feb 2005 22:05:05 +0900 (JST) Received: from mailsv.linux.bs1.fc.nec.co.jp (IDENT:postfix@namesv2.linux.bs1.fc.nec.co.jp [10.34.125.2]) by mailsv.bs1.fc.nec.co.jp (8.12.10/3.7W-HPC5.2F(mailsv)04081615) with ESMTP id j11CuuIK011793; Tue, 1 Feb 2005 21:56:58 +0900 (JST) Received: from [10.34.125.249] (sanma.linux.bs1.fc.nec.co.jp [10.34.125.249]) by mailsv.linux.bs1.fc.nec.co.jp (Postfix) with ESMTP id A5BE030806; Tue, 1 Feb 2005 22:05:03 +0900 (JST) Message-ID: <41FF7EB3.2090409@ak.jp.nec.com> Date: Tue, 01 Feb 2005 22:05:55 +0900 From: Kaigai Kohei User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Jackson , erikj@subway.americas.sgi.com Cc: pagg@oss.sgi.com, limin@dbear.engr.sgi.com, lse-tech@lists.sourceforge.net, guillaume.thouvenin@bull.net Subject: Re: CpuSet on PAGG (Re: PAGG in Open Source projects?) References: <41F8E117.5030501@ak.jp.nec.com> <20050127081753.5a9d16af.pj@sgi.com> <41FA330A.2030303@ak.jp.nec.com> <20050128050807.24018fb3.pj@sgi.com> <41FDFCDC.8080504@ak.jp.nec.com> <20050131030715.05cbb981.pj@sgi.com> In-Reply-To: <20050131030715.05cbb981.pj@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 88 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: kaigai@ak.jp.nec.com Precedence: bulk X-list: pagg 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 From pj@sgi.com Tue Feb 1 08:12:58 2005 Received: with ECARTIS (v1.0.0; list pagg); Tue, 01 Feb 2005 08:13:02 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j11GCuLK011540 for ; Tue, 1 Feb 2005 08:12:57 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j11GCuxT014906 for ; Tue, 1 Feb 2005 10:12:56 -0600 Received: from vpn2 (mtv-vpn-hw-pj-2.corp.sgi.com [134.15.25.219]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id j11GCsRF17979408; Tue, 1 Feb 2005 08:12:54 -0800 (PST) Date: Tue, 1 Feb 2005 08:12:53 -0800 From: Paul Jackson To: Kaigai Kohei Cc: erikj@subway.americas.sgi.com, pagg@oss.sgi.com, limin@dbear.engr.sgi.com, lse-tech@lists.sourceforge.net, guillaume.thouvenin@bull.net Subject: Re: CpuSet on PAGG (Re: PAGG in Open Source projects?) Message-Id: <20050201081253.76aba5c3.pj@sgi.com> In-Reply-To: <41FF7EB3.2090409@ak.jp.nec.com> References: <41F8E117.5030501@ak.jp.nec.com> <20050127081753.5a9d16af.pj@sgi.com> <41FA330A.2030303@ak.jp.nec.com> <20050128050807.24018fb3.pj@sgi.com> <41FDFCDC.8080504@ak.jp.nec.com> <20050131030715.05cbb981.pj@sgi.com> <41FF7EB3.2090409@ak.jp.nec.com> Organization: SGI X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 89 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: pagg 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 1.650.933.1373, 1.925.600.0401 From erikj@subway.americas.sgi.com Wed Feb 2 07:06:30 2005 Received: with ECARTIS (v1.0.0; list pagg); Wed, 02 Feb 2005 07:06:33 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j12F6TPM028422 for ; Wed, 2 Feb 2005 07:06:29 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j12GZWPt023322 for ; Wed, 2 Feb 2005 08:35:32 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j12F5RF31239926; Wed, 2 Feb 2005 09:05:28 -0600 (CST) Received: from subway.americas.sgi.com (subway.americas.sgi.com [128.162.236.152]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id j12F5QtC21621451; Wed, 2 Feb 2005 09:05:27 -0600 (CST) Received: from subway.americas.sgi.com (localhost [127.0.0.1]) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id j12F5PeZ978431; Wed, 2 Feb 2005 09:05:26 -0600 (CST) Received: from localhost (erikj@localhost) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) with ESMTP id j12F5KMv979077; Wed, 2 Feb 2005 09:05:21 -0600 (CST) Date: Wed, 2 Feb 2005 09:05:19 -0600 From: Erik Jacobson To: Kaigai Kohei cc: Paul Jackson , pagg@oss.sgi.com, limin@dbear.engr.sgi.com, lse-tech@lists.sourceforge.net, guillaume.thouvenin@bull.net Subject: Re: CpuSet on PAGG (Re: PAGG in Open Source projects?) In-Reply-To: <41FF7EB3.2090409@ak.jp.nec.com> Message-ID: References: <41F8E117.5030501@ak.jp.nec.com> <20050127081753.5a9d16af.pj@sgi.com> <41FA330A.2030303@ak.jp.nec.com> <20050128050807.24018fb3.pj@sgi.com> <41FDFCDC.8080504@ak.jp.nec.com> <20050131030715.05cbb981.pj@sgi.com> <41FF7EB3.2090409@ak.jp.nec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 90 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: erikj@subway.americas.sgi.com Precedence: bulk X-list: pagg > 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. Sorry for the delay. I was on vacation. For (1) - can you give some examples? For (2) - If you look at the exec hook __pagg_exec function, we go through the list of paggs for the task that reached the hook, and we execute the associated function pointer (if it is assigned in the pagg hook). When we execute the associated exec function pointer, we pass a reference to the pagg in question. pagg_get I suppose is a tiny bit expensive but it only gets bad when there are lots of pagg associations for a given task. I assume this is your concern for (2) though, right? If we were to change this, what would you suggest? Recall that there is a data pointer in the pagg structure that kernel module "customers" can store stuff in on a per-task basis. One could envision look-up tables or something, but that seems only a little less expensive and more complicated. We're of course open to ideas and suggestions. Thank you. -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota From kaigai@ak.jp.nec.com Thu Feb 3 05:42:22 2005 Received: with ECARTIS (v1.0.0; list pagg); Thu, 03 Feb 2005 05:42:28 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13DgKpf022016 for ; Thu, 3 Feb 2005 05:42:21 -0800 Received: from mailgate4.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j13DfSe14569; Thu, 3 Feb 2005 22:41:28 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j13DfSs16019; Thu, 3 Feb 2005 22:41:28 +0900 (JST) Received: from mailsv.bs1.fc.nec.co.jp (venus.hpc.bs1.fc.nec.co.jp [10.34.77.164]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id j13DfR214160; Thu, 3 Feb 2005 22:41:27 +0900 (JST) Received: from mailsv.linux.bs1.fc.nec.co.jp (IDENT:postfix@namesv2.linux.bs1.fc.nec.co.jp [10.34.125.2]) by mailsv.bs1.fc.nec.co.jp (8.12.10/3.7W-HPC5.2F(mailsv)04081615) with ESMTP id j13DXAIK029513; Thu, 3 Feb 2005 22:33:11 +0900 (JST) Received: from [10.34.125.249] (sanma.linux.bs1.fc.nec.co.jp [10.34.125.249]) by mailsv.linux.bs1.fc.nec.co.jp (Postfix) with ESMTP id 373BD30806; Thu, 3 Feb 2005 22:41:26 +0900 (JST) Message-ID: <42022A37.9050402@ak.jp.nec.com> Date: Thu, 03 Feb 2005 22:42:15 +0900 From: Kaigai Kohei User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Jackson Cc: erikj@subway.americas.sgi.com, pagg@oss.sgi.com, limin@dbear.engr.sgi.com, lse-tech@lists.sourceforge.net, guillaume.thouvenin@bull.net Subject: Re: CpuSet on PAGG (Re: PAGG in Open Source projects?) References: <41F8E117.5030501@ak.jp.nec.com> <20050127081753.5a9d16af.pj@sgi.com> <41FA330A.2030303@ak.jp.nec.com> <20050128050807.24018fb3.pj@sgi.com> <41FDFCDC.8080504@ak.jp.nec.com> <20050131030715.05cbb981.pj@sgi.com> <41FF7EB3.2090409@ak.jp.nec.com> <20050201081253.76aba5c3.pj@sgi.com> In-Reply-To: <20050201081253.76aba5c3.pj@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 91 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: kaigai@ak.jp.nec.com Precedence: bulk X-list: pagg Hello, Paul. Thanks for your comments. >>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. Hmm..., 'Simple is the best' is truth, I also think. >>__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. No, semaphores always have possibility to block, and pagg_sem is also same. (Who dose need a never-blocking-semaphore?) When I modified the CpuSet feature for using PAGG, I noticed we need call pagg_get() from some critical sections. Thus, I modified PAGG to replace task->pagg_sem by RCU. pagg_get() does not block on the PAGG implemented by RCU. > 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)? For example, pid_array_load() in kernel/cpuset.c is relevant. (This is the Paul Jackson's original implementation.) int pid_array_load() { read_lock(&tasklist_lock); --------- do_each_thread(g, p) { ^ if (p->cpuset == cs) { | : Critical } Section } while_each_thread(g, p); | array_full: v read_unlock(&tasklist_lock); --------- } In this case, if CpuSet would be a PAGG's custmer, we call pagg_call() to refer the PAGG object related to each task under the read_lock(&tasklist_lock). Thus, pagg_get() must not block. >>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. Today, my colleague acclaim CpuSet also. :) It's good, if we can use CpuSet on stock-kernel. Thank you. -- Linux Promotion Center, NEC KaiGai Kohei From kaigai@ak.jp.nec.com Thu Feb 3 05:45:08 2005 Received: with ECARTIS (v1.0.0; list pagg); Thu, 03 Feb 2005 05:45:11 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j13Dj7O0022094 for ; Thu, 3 Feb 2005 05:45:07 -0800 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j13DiDM23093; Thu, 3 Feb 2005 22:44:13 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j13DiDB21136; Thu, 3 Feb 2005 22:44:13 +0900 (JST) Received: from mailsv.bs1.fc.nec.co.jp (venus.hpc.bs1.fc.nec.co.jp [10.34.77.164]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id j13DiCt02070; Thu, 3 Feb 2005 22:44:12 +0900 (JST) Received: from mailsv.linux.bs1.fc.nec.co.jp (IDENT:postfix@namesv2.linux.bs1.fc.nec.co.jp [10.34.125.2]) by mailsv.bs1.fc.nec.co.jp (8.12.10/3.7W-HPC5.2F(mailsv)04081615) with ESMTP id j13DZfIK029531; Thu, 3 Feb 2005 22:35:41 +0900 (JST) Received: from [10.34.125.249] (sanma.linux.bs1.fc.nec.co.jp [10.34.125.249]) by mailsv.linux.bs1.fc.nec.co.jp (Postfix) with ESMTP id 7DD9030806; Thu, 3 Feb 2005 22:43:57 +0900 (JST) Message-ID: <42022ACD.9000907@ak.jp.nec.com> Date: Thu, 03 Feb 2005 22:44:45 +0900 From: Kaigai Kohei User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Jacobson Cc: Paul Jackson , pagg@oss.sgi.com, limin@dbear.engr.sgi.com, lse-tech@lists.sourceforge.net, guillaume.thouvenin@bull.net Subject: Re: CpuSet on PAGG (Re: PAGG in Open Source projects?) References: <41F8E117.5030501@ak.jp.nec.com> <20050127081753.5a9d16af.pj@sgi.com> <41FA330A.2030303@ak.jp.nec.com> <20050128050807.24018fb3.pj@sgi.com> <41FDFCDC.8080504@ak.jp.nec.com> <20050131030715.05cbb981.pj@sgi.com> <41FF7EB3.2090409@ak.jp.nec.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 92 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: kaigai@ak.jp.nec.com Precedence: bulk X-list: pagg Hi, Erik. Thanks for your comments. Erik Jacobson wrote: >>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. > > > Sorry for the delay. I was on vacation. > > For (1) - can you give some examples? For example, I want to refer the PAGG object for each task when we scan the task-list under the read_lock(&tasklist_lock). Using semaphore for exclusion isn't appropriate st such times. And, we should avoid to use any kind of spinlock as possible as we can, because it's expencive. I think RCU is appropriate for alternative lockless method in this case. # RCU's bad point is current PAGG's custmer must be forced to modify # own implementation. > For (2) - If you look at the exec hook __pagg_exec function, we go through > the list of paggs for the task that reached the hook, and we execute the > associated function pointer (if it is assigned in the pagg hook). When we > execute the associated exec function pointer, we pass a reference to the pagg > in question. It's right when we are processing the hook function. But we can call pagg_get() to refer the PAGG object in other place. I think the issue of (2) is using string comparison in pagg_get and so on. Generically, string comparison is more expensive than integer one. Is it possible that PAGG-engine associates the unique integer key with PAGG's customer(such as Job) when pagg_hook_register() was called, and we can call pagg_get() with task_strcut and this integer key instead of PAGG-custmer's identical string(such as "job" or "cpuset") ? > pagg_get I suppose is a tiny bit expensive but it only gets bad when there > are lots of pagg associations for a given task. I assume this is your > concern for (2) though, right? That's right also, I think. But is it unavoidable ? > If we were to change this, what would you suggest? Recall that there is > a data pointer in the pagg structure that kernel module "customers" can > store stuff in on a per-task basis. One could envision look-up tables > or something, but that seems only a little less expensive and more > complicated. My proposal is that pagg_sem should be replaced by RCU for issue (1). For example, is it possible to abolish strcmp() for the issue (2) by the following method ? 1) pagg_hook_register() returns the unique integer key associated with PAGG's customer registered. 2) That unique integer key is made a key for finding the PAGG object. struct pagg * pagg_get(struct task_struct *task, int key){ struct pagg *pagg; list_for_each_entry(pagg, &task->pagg_list, entry) { if (key==pagg->key) return pagg; return NULL; } I expect that PAGG and PAGG's custmer such as Job is merged into up-stream kernel. Thanks. -- Linux Promotion Center, NEC KaiGai Kohei