From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Revert "local_t Documentation update"
Date: Wed, 16 Jan 2008 20:48:13 -0500 [thread overview]
Message-ID: <20080117014813.GA2322@Krystal> (raw)
In-Reply-To: <478EB2CC.8000900@cn.fujitsu.com>
* Li Zefan (lizf@cn.fujitsu.com) wrote:
> This reverts commit e1265205c0ee3919c3f2c750662630154c8faab2.
>
> It's a duplicate commit of commit 74beb9db77930be476b267ec8518a642f39a04bf,
> resulting in a duplicate section.
>
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
>
Thanks, I guess it's been merged twice somehow :S
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> ---
> Documentation/local_ops.txt | 23 -----------------------
> 1 files changed, 0 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/local_ops.txt b/Documentation/local_ops.txt
> index 1a45f11..4269a11 100644
> --- a/Documentation/local_ops.txt
> +++ b/Documentation/local_ops.txt
> @@ -68,29 +68,6 @@ typedef struct { atomic_long_t a; } local_t;
> variable can be read when reading some _other_ cpu's variables.
>
>
> -* Rules to follow when using local atomic operations
> -
> -- Variables touched by local ops must be per cpu variables.
> -- _Only_ the CPU owner of these variables must write to them.
> -- This CPU can use local ops from any context (process, irq, softirq, nmi, ...)
> - to update its local_t variables.
> -- Preemption (or interrupts) must be disabled when using local ops in
> - process context to make sure the process won't be migrated to a
> - different CPU between getting the per-cpu variable and doing the
> - actual local op.
> -- When using local ops in interrupt context, no special care must be
> - taken on a mainline kernel, since they will run on the local CPU with
> - preemption already disabled. I suggest, however, to explicitly
> - disable preemption anyway to make sure it will still work correctly on
> - -rt kernels.
> -- Reading the local cpu variable will provide the current copy of the
> - variable.
> -- Reads of these variables can be done from any CPU, because updates to
> - "long", aligned, variables are always atomic. Since no memory
> - synchronization is done by the writer CPU, an outdated copy of the
> - variable can be read when reading some _other_ cpu's variables.
> -
> -
> * How to use local atomic operations
>
> #include <linux/percpu.h>
> --
> 1.5.3.rc7
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-01-17 1:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 1:43 [PATCH] Revert "local_t Documentation update" Li Zefan
2008-01-17 1:48 ` Mathieu Desnoyers [this message]
2008-01-17 1:55 ` Li Zefan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080117014813.GA2322@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox