[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <490E094F.7090007@colorfullife.com>
Date: Sun, 02 Nov 2008 21:10:55 +0100
From: Manfred Spraul <manfred@...orfullife.com>
To: paulmck@...ux.vnet.ibm.com
CC: linux-kernel@...r.kernel.org, cl@...ux-foundation.org,
mingo@...e.hu, akpm@...ux-foundation.org, dipankar@...ibm.com,
josht@...ux.vnet.ibm.com, schamp@....com, niv@...ibm.com,
dvhltc@...ibm.com, ego@...ibm.com, laijs@...fujitsu.com,
rostedt@...dmis.org, peterz@...radead.org, penberg@...helsinki.fi,
andi@...stfloor.org, tglx@...utronix.de
Subject: Re: [PATCH, RFC] v7 scalable classic RCU implementation
Paul E. McKenney wrote:
> --- /dev/null
> +++ b/Documentation/RCU/trace.txt
> @@ -0,0 +1,398 @@
> +CONFIG_RCU_TRACE debugfs Files and Formats
> +
> +
> +The rcupreempt and rcutree implementations of RCU provide debugfs trace
> +output that summarizes counters and state. This information is useful for
> +debugging RCU itself, and can sometimes also help to debug abuses of RCU.
> +Note that the rcuclassic implementation of RCU does not provide debugfs
> +trace output.
> +
>
What about some generic files, with the same content for all rcu backends?
The implementation could be in rcupdate.c. At least counting the rcu
callbacks could be done from generic code, the grace periods could be
queried [Do all backends implement rcu_batches_completed?]
Attached is a hack that I use right now for myself.
Btw - on my 4-cpu system, the average latency from call_rcu() to the rcu
callback is 4-5 milliseconds, (CONFIG_HZ_1000).
--
Manfred
View attachment "patch-rcu-generic-trace" of type "text/plain" (7884 bytes)
Powered by blists - more mailing lists