This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] local_t : Documentation - update
- From: Pavel Machek <pavel at ucw dot cz>
- To: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Cc: linux-kernel at vger dot kernel dot org, Andrew Morton <akpm at osdl dot org>, Ingo Molnar <mingo at redhat dot com>, Greg Kroah-Hartman <gregkh at suse dot de>, Christoph Hellwig <hch at infradead dot org>, ltt-dev at shafik dot org, systemtap at sources dot redhat dot com, Douglas Niehaus <niehaus at eecs dot ku dot edu>, "Martin J. Bligh" <mbligh at mbligh dot org>, Thomas Gleixner <tglx at linutronix dot de>
- Date: Wed, 10 Jan 2007 00:45:11 +0100
- Subject: Re: [PATCH] local_t : Documentation - update
- References: <20061221001545.GP28643@Krystal> <20061223093358.GF3960@ucw.cz> <20070109031446.GA29426@Krystal> <20070109224100.GB6555@elf.ucw.cz> <20070109232155.GA25387@Krystal>
Hi!
> > AFAICT this fails to mention... Is local_t as big as int? As big as
> > long? Or perhaps smaller because high bits may be needed for locking?
>
> Hi Pavel,
>
> Here is an update that adds the information you mentionned in this reply and the
> one to Andrew. Thanks for the comments.
>
> Mathieu
>
>
> index dfeec94..bd854b3 100644
> --- a/Documentation/local_ops.txt
> +++ b/Documentation/local_ops.txt
> @@ -22,6 +22,13 @@ require disabling interrupts to protect from interrupt handlers and it permits
> coherent counters in NMI handlers. It is especially useful for tracing purposes
> and for various performance monitoring counters.
>
> +Local atomic operations only guarantee variable modification atomicity wrt the
> +CPU which owns the data. Therefore, care must taken to make sure that only one
> +CPU writes to the local_t data. This is done by using per cpu data and making
> +sure that we modify it from within a preemption safe context. It is however
> +permitted to read local_t data from any CPU : it will then appear to be written
> +out of order wrt other memory writes on the owner CPU.
So it is "one cpu may write, other cpus may read", and as big as
long. Are you sure obscure architectures (sparc?) can implement this
in useful way? ... maybe yes, unless obscure architecture exists where
second other cpu can see garbage data when first cpu writes into long
...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html