From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
Date: Fri, 28 Oct 2011 04:52:56 +0200 [thread overview]
Message-ID: <1319770376.23112.58.camel@edumazet-laptop> (raw)
In-Reply-To: <1319766293.6759.17.camel@deadeye>
Le vendredi 28 octobre 2011 à 02:44 +0100, Ben Hutchings a écrit :
> Whether or not it needs to provide any ordering guarantee, atomic_read()
> must never read more than once, and I think that requires the volatile
> qualification. It might be clearer to use the ACCESS_ONCE macro,
> however.
>
Where this requirement comes from ?
Maybe then introduce atomic_read_once() for users really needing it :)
ACCESS_ONCE will force the read/move instruction I try to avoid :(
By the way, removing volatile on my x86_64 defconfig saves a bit of
space :
# size vmlinux vmlinux.old
text data bss dec hex filename
10907585 2890992 1540096 15338673 ea0cb1 vmlinux
10912342 2891056 1540096 15343494 ea1f86 vmlinux.old
booted and everything seems fine, but obviously lightly tested...
Note : There is still one useless access to page-flags,
'fixing' atomic_read() is not enough.
0,04 : ffffffff815e4675: je ffffffff815e4870 <tcp_sendmsg+0xc80>
0,08 : ffffffff815e467b: mov (%r9),%rax // useless
2,08 : ffffffff815e467e: lock incl 0x1c(%r9)
3,58 : ffffffff815e4683: mov (%r9),%rax
0,04 : ffffffff815e4686: test $0x80,%ah
0,00 : ffffffff815e4689: jne ffffffff815e48ee <tcp_sendmsg+0xcfe>
next prev parent reply other threads:[~2011-10-28 2:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-28 1:19 [RFC] should VM_BUG_ON(cond) really evaluate cond Eric Dumazet
2011-10-28 1:25 ` Andi Kleen
2011-10-28 1:34 ` Linus Torvalds
2011-10-28 1:44 ` Ben Hutchings
2011-10-28 2:52 ` Eric Dumazet [this message]
2011-10-28 3:29 ` Ben Hutchings
2011-10-28 4:43 ` >Re: " Eric Dumazet
2011-10-28 11:37 ` Linus Torvalds
2011-10-28 12:09 ` Eric Dumazet
2011-10-28 12:19 ` Linus Torvalds
2011-10-28 12:40 ` Linus Torvalds
2011-10-28 14:47 ` Eric Dumazet
2011-10-28 14:55 ` Linus Torvalds
2011-10-29 15:43 ` Eric Dumazet
2011-10-29 17:34 ` Linus Torvalds
2011-10-30 8:52 ` Eric Dumazet
2011-10-30 9:59 ` Andi Kleen
2011-10-30 15:16 ` Eric Dumazet
2011-10-30 17:07 ` Linus Torvalds
2011-10-30 17:41 ` Eric Dumazet
2011-10-30 17:48 ` Linus Torvalds
2011-10-30 17:59 ` Eric Dumazet
2011-10-30 18:09 ` Linus Torvalds
2011-11-02 0:14 ` Eric Dumazet
2011-11-01 4:06 ` Stephen Rothwell
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=1319770376.23112.58.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=bhutchings@solarflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).