local_t Documentation update 2
(this patch seems to have fallen off the grid, but is still providing
useful information. It applies to 2.6.23-mm1.)
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to
local_t Documentation update 2
(this patch seems to have fallen off the grid, but is still providing
useful information. It applies to 2.6.23-mm1.)
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to
On Wed, Aug 29, 2007 at 08:19:53AM -0400, Mathieu Desnoyers wrote:
> local_t Documentation update 2
>
> Grant Grundler was asking for more detail about correct usage of local atomic
> operations and suggested adding the resulting summary to local_ops.txt.
>
> "Please add a bit more detail. If
local_t Documentation update 2
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to local_ops.txt.
"Please add a bit more detail. If DaveM is correct (he normally is), then
there must be limits on how the local_t
local_t Documentation update 2
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to local_ops.txt.
Please add a bit more detail. If DaveM is correct (he normally is), then
there must be limits on how the local_t
On Wed, Aug 29, 2007 at 08:19:53AM -0400, Mathieu Desnoyers wrote:
local_t Documentation update 2
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to local_ops.txt.
Please add a bit more detail. If DaveM is
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> > 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
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> > 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.
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.
>
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> 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?
>
> Pavel
>
Hi Pavel,
Here is
Hi!
> > > These patches extend and standardise local_t operations on each
> > > architectures,
> > > allowing a rich set of atomic operations to be done on per-cpu data with
> > > minimal performance impact. On some architectures, there seems to be no
> > > difference between the SMP and UP
On Tue 2007-01-09 13:01:10, Andrew Morton wrote:
> On Mon, 8 Jan 2007 22:14:46 -0500
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > +* How to use local atomic operations
> > +
> > +#include
> > +#include
> > +
> > +static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0);
> > +
> > +
> >
On Tue, 9 Jan 2007 17:06:16 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> * Andrew Morton ([EMAIL PROTECTED]) wrote:
> > On Mon, 8 Jan 2007 22:14:46 -0500
> > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> >
> > > +* How to use local atomic operations
> > > +
> > > +#include
> > >
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Mon, 8 Jan 2007 22:14:46 -0500
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > +* How to use local atomic operations
> > +
> > +#include
> > +#include
> > +
> > +static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0);
> > +
> > +
> > +*
On Mon, 8 Jan 2007 22:14:46 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> +* How to use local atomic operations
> +
> +#include
> +#include
> +
> +static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0);
> +
> +
> +* Counting
> +
> +In preemptible context, use get_cpu_var() and
On Mon, 8 Jan 2007 22:14:46 -0500
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
+* How to use local atomic operations
+
+#include linux/percpu.h
+#include asm/local.h
+
+static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0);
+
+
+* Counting
+
+In preemptible context, use get_cpu_var()
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Mon, 8 Jan 2007 22:14:46 -0500
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
+* How to use local atomic operations
+
+#include linux/percpu.h
+#include asm/local.h
+
+static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0);
+
+
+*
On Tue, 9 Jan 2007 17:06:16 -0500
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Mon, 8 Jan 2007 22:14:46 -0500
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
+* How to use local atomic operations
+
+#include linux/percpu.h
+#include
On Tue 2007-01-09 13:01:10, Andrew Morton wrote:
On Mon, 8 Jan 2007 22:14:46 -0500
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
+* How to use local atomic operations
+
+#include linux/percpu.h
+#include asm/local.h
+
+static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0);
+
+
Hi!
These patches extend and standardise local_t operations on each
architectures,
allowing a rich set of atomic operations to be done on per-cpu data with
minimal performance impact. On some architectures, there seems to be no
difference between the SMP and UP operation (same
* Pavel Machek ([EMAIL PROTECTED]) wrote:
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?
Pavel
Hi Pavel,
Here is an
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
* Pavel Machek ([EMAIL PROTECTED]) wrote:
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
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
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
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
>
> > These patches extend and standardise local_t operations on each
> > architectures,
> > allowing a rich set of atomic operations to be done on per-cpu data with
> > minimal performance impact. On some architectures, there seems to be no
> >
* Pavel Machek ([EMAIL PROTECTED]) wrote:
Hi!
These patches extend and standardise local_t operations on each
architectures,
allowing a rich set of atomic operations to be done on per-cpu data with
minimal performance impact. On some architectures, there seems to be no
difference
26 matches
Mail list logo
