From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Miller <davem@davemloft.net>
Cc: jslaby@novell.com, jirislaby@gmail.com, mingo@elte.hu,
nhorman@tuxdriver.com, sfr@canb.auug.org.au,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
marcin.slusarz@gmail.com, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, jmorris@namei.org, heiko.carstens@de.ibm.com,
sparclinux@vger.kernel.org
Subject: Re: [PATCH 06/16] SPARC: use ACCESS_ONCE for rlimits
Date: Wed, 18 Nov 2009 10:09:05 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.01.0911181000020.4644@localhost.localdomain> (raw)
In-Reply-To: <20091118.095526.43570583.davem@davemloft.net>
On Wed, 18 Nov 2009, David Miller wrote:
>
> But I wonder have we really seen the compiler create this
> kind of situation? Or is this patch series based upon the
> fact that it "could happen"?
We have seen things like that in practice - where the compiler re-loads a
value twice, rather than use a copy like the source code did.
That said, it's rare, to the point of being _almost_ unheard of. It's much
more common that gcc generates bad code by doing the reverse (trying to
keep things in registers and spilling, instead of just re-generating the
value). There are very very few cases where ACCESS_ONCE() actually matters
for correctness.
Because in practice, the value is either modified some way (and spilling
it is cheaper than re-computing the modification), or there's just some
operation that might act as a memory barrier and alias the original memory
location so gcc wouldn't dare re-load anyway.
However, one of the nice things about ACCESS_ONCE() is that it's also a
big flag for "this value is loaded without locking, on purpose".
So even if it doesn't then actually change code generation significantly
(most common end result especially on x86 that has most ALU instructions
taking memory operations: gcc generates slightly worse code due to getting
nervous about 'volatile' and not combining instructions), it's a big
honking piece of programmer documentation: look out!
It's basically a heads-up for lockless programming like RCU. As such, it
can be something scary, but when it's done right, it's a good thing. And I
think that for rlimits, we do have a good reason to say "sure, somebody
else may change the limit values concurrently, but we don't really care:
we just want _one_ value, whether it's the old or the new one".
That said, the patch you Ack'ed is in the series of patches that I hated,
and Nak'ed for other reasons (namely "-EEXPRESSIONTOOCOMPLICATEDTOLIVE").
Linus
WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Miller <davem@davemloft.net>
Cc: jslaby@novell.com, jirislaby@gmail.com, mingo@elte.hu,
nhorman@tuxdriver.com, sfr@canb.auug.org.au,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
marcin.slusarz@gmail.com, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, jmorris@namei.org, heiko.carstens@de.ibm.com,
sparclinux@vger.kernel.org
Subject: Re: [PATCH 06/16] SPARC: use ACCESS_ONCE for rlimits
Date: Wed, 18 Nov 2009 18:09:05 +0000 [thread overview]
Message-ID: <alpine.LFD.2.01.0911181000020.4644@localhost.localdomain> (raw)
In-Reply-To: <20091118.095526.43570583.davem@davemloft.net>
On Wed, 18 Nov 2009, David Miller wrote:
>
> But I wonder have we really seen the compiler create this
> kind of situation? Or is this patch series based upon the
> fact that it "could happen"?
We have seen things like that in practice - where the compiler re-loads a
value twice, rather than use a copy like the source code did.
That said, it's rare, to the point of being _almost_ unheard of. It's much
more common that gcc generates bad code by doing the reverse (trying to
keep things in registers and spilling, instead of just re-generating the
value). There are very very few cases where ACCESS_ONCE() actually matters
for correctness.
Because in practice, the value is either modified some way (and spilling
it is cheaper than re-computing the modification), or there's just some
operation that might act as a memory barrier and alias the original memory
location so gcc wouldn't dare re-load anyway.
However, one of the nice things about ACCESS_ONCE() is that it's also a
big flag for "this value is loaded without locking, on purpose".
So even if it doesn't then actually change code generation significantly
(most common end result especially on x86 that has most ALU instructions
taking memory operations: gcc generates slightly worse code due to getting
nervous about 'volatile' and not combining instructions), it's a big
honking piece of programmer documentation: look out!
It's basically a heads-up for lockless programming like RCU. As such, it
can be something scary, but when it's done right, it's a good thing. And I
think that for rlimits, we do have a good reason to say "sure, somebody
else may change the limit values concurrently, but we don't really care:
we just want _one_ value, whether it's the old or the new one".
That said, the patch you Ack'ed is in the series of patches that I hated,
and Nak'ed for other reasons (namely "-EEXPRESSIONTOOCOMPLICATEDTOLIVE").
Linus
next prev parent reply other threads:[~2009-11-18 18:10 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 20:06 [PATCH] proc: augment /proc/pid/limits to allow setting of process limits Neil Horman
2009-09-28 22:44 ` Andrew Morton
2009-09-29 1:14 ` Neil Horman
2009-09-29 20:25 ` [PATCH] proc: augment /proc/pid/limits to allow setting of process limits (v2) Neil Horman
2009-09-29 20:46 ` Andrew Morton
2009-09-30 0:59 ` Neil Horman
2009-10-01 17:15 ` [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v3) Neil Horman
2009-10-01 17:16 ` [PATCH 1/3] " Neil Horman
2009-10-04 12:14 ` Marcin Slusarz
2009-10-04 16:50 ` Neil Horman
2009-10-04 20:04 ` Marcin Slusarz
2009-10-04 23:10 ` Neil Horman
2009-10-04 20:30 ` Marcin Slusarz
2009-10-01 17:21 ` [PATCH 2/3] " Neil Horman
2009-10-01 17:22 ` [PATCH 3/3] " Neil Horman
2009-10-05 0:26 ` [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v4) Neil Horman
2009-10-05 0:53 ` [PATCH 1/3] " Neil Horman
2009-10-08 21:32 ` Marcin Slusarz
2009-10-09 2:00 ` Neil Horman
2009-10-05 0:54 ` [PATCH 2/3] " Neil Horman
2009-10-05 1:57 ` Américo Wang
2009-10-05 12:32 ` Neil Horman
2009-10-05 0:54 ` [PATCH 3/3] " Neil Horman
2009-10-12 16:13 ` [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v5) Neil Horman
2009-10-12 16:20 ` [PATCH 1/3] " Neil Horman
2009-10-12 16:25 ` [PATCH 2/3] " Neil Horman
2009-10-12 16:27 ` [PATCH 3/3] " Neil Horman
2009-10-12 20:13 ` [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v6) Neil Horman
2009-10-12 20:20 ` [PATCH 1/3] " Neil Horman
2009-10-12 20:23 ` [PATCH 2/3] " Neil Horman
2009-10-12 20:25 ` [PATCH 3/3] " Neil Horman
2009-10-20 0:52 ` [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v7) Neil Horman
2009-10-20 0:53 ` [PATCH 1/3] " Neil Horman
2009-10-20 0:54 ` [PATCH 2/3] " Neil Horman
2009-11-02 15:10 ` Ingo Molnar
2009-11-02 17:40 ` Neil Horman
2009-10-20 0:55 ` [PATCH 3/3] " Neil Horman
2009-10-28 14:44 ` [PATCH 0/3] " Neil Horman
2009-10-30 18:24 ` Neil Horman
2009-11-02 15:25 ` Ingo Molnar
2009-11-02 17:54 ` Neil Horman
2009-11-02 18:51 ` Ingo Molnar
2009-11-03 0:23 ` Neil Horman
2009-11-04 11:26 ` Ingo Molnar
2009-11-05 20:48 ` Neil Horman
2009-11-06 9:26 ` Ingo Molnar
2009-11-06 10:00 ` Jiri Slaby
2009-11-08 10:36 ` Ingo Molnar
2009-11-09 0:10 ` Neil Horman
2009-11-09 8:32 ` Jiri Slaby
2009-11-09 13:34 ` Neil Horman
2009-11-09 8:54 ` Jiri Slaby
2009-11-09 9:01 ` Ingo Molnar
2009-11-09 9:22 ` Jiri Slaby
2009-11-09 9:26 ` Ingo Molnar
2009-11-09 13:35 ` Neil Horman
2009-11-09 15:56 ` Jiri Slaby
2009-11-09 16:40 ` Oleg Nesterov
2009-11-09 17:15 ` Jiri Slaby
2009-11-09 17:26 ` Linus Torvalds
2009-11-09 17:36 ` Oleg Nesterov
2009-11-18 14:51 ` Jiri Slaby
2009-11-18 14:51 ` [PATCH 01/16] core: posix-cpu-timers, cleanup rlimits usage Jiri Slaby
2009-11-18 16:48 ` Peter Zijlstra
2009-11-18 14:51 ` [PATCH 02/16] core: do security check under task_lock Jiri Slaby
2009-11-18 21:47 ` James Morris
2009-11-18 14:51 ` [PATCH 03/16] IA64: use ACCESS_ONCE for rlimits Jiri Slaby
2009-11-18 14:51 ` Jiri Slaby
2009-11-18 18:56 ` Luck, Tony
2009-11-18 18:56 ` Luck, Tony
2009-11-18 19:48 ` Linus Torvalds
2009-11-18 19:48 ` Linus Torvalds
2009-11-19 2:28 ` Ingo Molnar
2009-11-19 2:28 ` Ingo Molnar
2009-11-18 14:51 ` [PATCH 04/16] PPC: " Jiri Slaby
2009-11-18 14:51 ` Jiri Slaby
2009-11-18 14:51 ` [PATCH 05/16] S390: " Jiri Slaby
2009-11-18 14:51 ` [PATCH 06/16] SPARC: " Jiri Slaby
2009-11-18 14:51 ` Jiri Slaby
2009-11-18 17:55 ` David Miller
2009-11-18 17:55 ` David Miller
2009-11-18 18:09 ` Linus Torvalds [this message]
2009-11-18 18:09 ` Linus Torvalds
2009-11-18 14:51 ` [PATCH 07/16] X86: " Jiri Slaby
2009-11-18 14:51 ` [PATCH 08/16] FS: " Jiri Slaby
2009-11-18 14:51 ` [PATCH 09/16] MM: " Jiri Slaby
2009-11-18 14:51 ` Jiri Slaby
2009-11-18 15:29 ` Linus Torvalds
2009-11-18 15:29 ` Linus Torvalds
2009-11-18 14:51 ` [PATCH 10/16] core: " Jiri Slaby
[not found] ` <4B040A03.2020508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-11-18 14:51 ` [PATCH 11/16] misc: " Jiri Slaby
2009-11-18 14:51 ` Jiri Slaby
2009-11-18 14:51 ` [PATCH 12/16] core: rename setrlimit to do_setrlimit Jiri Slaby
2009-11-20 6:10 ` Américo Wang
2009-11-18 14:51 ` [PATCH 13/16] core: implement getprlimit and setprlimit syscalls Jiri Slaby
2009-11-20 13:14 ` Neil Horman
2009-11-18 14:52 ` [PATCH 14/16] unistd: add __NR_[get|set]prlimit syscall numbers Jiri Slaby
2009-11-18 14:52 ` [PATCH 15/16] COMPAT: add get/put_compat_rlimit Jiri Slaby
2009-12-30 23:55 ` Arnd Bergmann
2010-01-06 9:35 ` Jiri Slaby
2009-11-18 14:52 ` [PATCH 16/16] x86: add ia32 compat prlimit syscalls Jiri Slaby
2009-11-18 23:15 ` [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v7) Oleg Nesterov
2009-11-19 15:43 ` Jiri Slaby
2009-11-20 2:11 ` acct_file_reopen() && do_acct_process() (Was: [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v7)) Oleg Nesterov
2009-11-20 10:27 ` Jiri Slaby
2009-10-12 21:58 ` [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v5) Andrew Morton
2009-10-13 0:06 ` Neil Horman
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=alpine.LFD.2.01.0911181000020.4644@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=jirislaby@gmail.com \
--cc=jmorris@namei.org \
--cc=jslaby@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.slusarz@gmail.com \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=nhorman@tuxdriver.com \
--cc=sfr@canb.auug.org.au \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.