Re: [RFC,PATCH] RCUify single-thread case of clock_gettime()

[Joe Seigh <jseigh_02@xemaps.com>]

Paul E. McKenney wrote:
> Hello!
>
> The attached patch uses RCU to avoid the need to acquire tasklist_lock
> in the single-thread case of clock_gettime().  Still acquires tasklist_lock
> when asking for the time of a (potentially multithreaded) process.
>
> Experimental, has been touch-tested on x86 and POWER.  Requires RCU on
> task_struct.  Further more focused testing in progress.
>
> Thoughts?  (Why?  Some off-list users want to be able to monitor CPU
> consumption of specific threads.  They need to do so quite frequently,
> so acquiring tasklist_lock is inappropriate.)


I'd like to see the time the thread is dispatched put into a read only
memory segment along with a virtual timer and real timer offsets.  The
thread gets the read or virtual time by reading the virtual offset,
reading the real clock (whatever that is), rereading the virtual offset,
and if that hasn't changed, getting the desired timer value by adding the
appropiate offset.  No kernel entanglements required.  This is an old
trick VM used to support virtual timers for MVS.

And while we're at it, throw in the rest of the thread usage stats.

The use of mapped memory segments to avoid syscalls is a good idea.  relayfs
has already established that precedent.  relayfs only handles circular
producer/consumer queues but you could use RCU for preeemptive user threads
or RCU+SMR for other data structures in mapped memory managed by the kernel
or another process even.


--
Joe Seigh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/