From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756215AbZBIR74 (ORCPT ); Mon, 9 Feb 2009 12:59:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755035AbZBIR7q (ORCPT ); Mon, 9 Feb 2009 12:59:46 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]:54230 "EHLO e1.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754987AbZBIR7p (ORCPT ); Mon, 9 Feb 2009 12:59:45 -0500 Date: Mon, 9 Feb 2009 09:59:43 -0800 From: "Paul E. McKenney" To: Bert Wesarg Cc: Mathieu Desnoyers , ltt-dev@lists.casi.polymtl.ca, linux-kernel@vger.kernel.org, Robert Wisniewski Subject: Re: [RFC git tree] Userspace RCU (urcu) for Linux (repost) Message-ID: <20090209175943.GF6802@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20090206163432.GF10918@linux.vnet.ibm.com> <20090208224419.GA19512@Krystal> <20090209041153.GR7120@linux.vnet.ibm.com> <20090209045352.GA28653@Krystal> <20090209131653.GS7120@linux.vnet.ibm.com> <36ca99e90902090919r297ad4c3re2248c321b36baf8@mail.gmail.com> <20090209173427.GC6802@linux.vnet.ibm.com> <36ca99e90902090935u7fef1cb1g27303e546527e3d8@mail.gmail.com> <20090209174030.GD6802@linux.vnet.ibm.com> <36ca99e90902090945t8ae9792j84ca940f62414a48@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36ca99e90902090945t8ae9792j84ca940f62414a48@mail.gmail.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 09, 2009 at 06:45:05PM +0100, Bert Wesarg wrote: > On Mon, Feb 9, 2009 at 18:40, Paul E. McKenney > wrote: > > On Mon, Feb 09, 2009 at 06:35:38PM +0100, Bert Wesarg wrote: > >> On Mon, Feb 9, 2009 at 18:34, Paul E. McKenney > >> wrote: > >> > On Mon, Feb 09, 2009 at 06:19:45PM +0100, Bert Wesarg wrote: > >> >> On Mon, Feb 9, 2009 at 14:16, Paul E. McKenney > >> >> wrote: > >> >> > On Sun, Feb 08, 2009 at 11:53:52PM -0500, Mathieu Desnoyers wrote: > >> >> >> Yes, I guess the signal is not so bad. > >> >> > > >> >> > Now if there were a /proc entry that listed out the tids of the > >> >> > currently running threads, then it might be possible to do something, > >> >> > especially for applications with many more threads than CPUs. > >> >> > >> >> Do you mean something like: `ls /proc/$pid/tasks/*`? Or is this not > >> >> atomic enough? > >> > > >> > Won't that give me all the threads rather than only the ones currently > >> > running? > >> > >> What do you mean by 'running'? > > > > Sitting on a CPU and executing, as opposed to blocked or preempted. > > Ok, me too. > > > It is pretty easy to scan the running tasks within the kernel, but I > > don't know of an efficient way to do it from user mode. The only way > > I know of would be to cat out the /proc/$pid/tasks/*/status (IIRC) > > and look for the task state. > > Yes, me too. I was afraid of that... ;-) Do you believe that something like a /proc/runningtids that listsd currently running tasks be useful in general? Or just to this algorithm? Thanx, Paul