On Mon, Aug 13, 2007 at 01:19:31PM +0100, Russell King wrote:
On Mon, Aug 13, 2007 at 07:09:46AM -0400, Chris Snook wrote:
By popular demand, I've redone the patchset to include volatile casts in
atomic_set as well. I've also converted the macros to inline functions, to
help catch type
Joe Perches wrote:
On Mon, 2007-08-13 at 02:49 -0400, Chris Snook wrote:
Actually, now that I've seen the format in the intro patch,
it would be simpler just to use this:
F: drivers/net/atl1/
ATL1 ETHERNET DRIVER
P: Jay Cliburn
M: [EMAIL PROTECTED]
P: Chris Snook
M
Luck, Tony wrote:
Use volatile consistently in atomic.h on ia64.
This will do weird things without Andreas Schwab's fix:
http://lkml.org/lkml/2007/8/10/410
The build is very noisy with the inline versions of atomic_{read,set}
and their 64-bit siblings. Here are the prime culprits (some of
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Luck, Tony wrote:
I re-tried the macros ... the three warnings from mm/slub.c all result in
broken code ... and quite rightly too, they all come from code that does:
atomic_read(n-nr_slabs)
But the nr_slabs field is an atomic_long_t, so
Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable as volatile in
atomic_read
Christoph Lameter wrote:
On Mon, 13 Aug 2007, Chris Snook wrote:
@@ -38,7 +45,7 @@
Next, we have:
- #define atomic_read(v) ((v)-counter)
+ #define atomic_read(v) (*(volatile int *)(v)-counter)
which simply reads the current value of the counter.
volatile means
Satyam Sharma wrote:
On Tue, 14 Aug 2007, Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Chris Snook wrote:
volatile means that there is some vague notion of read it now. But that
really does not exist. Instead we control visibility via barriers (smp_wmb,
smp_rmb). Would it not be best to not have volatile at all in atomic
operations
Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
Because atomic operations are generally used for synchronization, which requires
volatile behavior. Most such codepaths currently use an inefficient barrier().
Some forget to and we get bugs, because people assume that atomic_read
Herbert Xu wrote:
Andi Kleen [EMAIL PROTECTED] wrote:
My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
textdata bss dec hex filename
3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
3435308 249176 176128 3860612 3ae884 atomic_inlineasm/vmlinux
In the fallout from the recent atomic_t volatility discussions, patches
have been posted to moot the compiler correctness issues by implementing
atomic[64]_[read|set] in inline assembly on powerpc, i386, and x86_64.
While I personally don't consider such implementations to be critically
Herbert Xu wrote:
On Wed, Aug 15, 2007 at 01:02:23PM -0400, Chris Snook wrote:
Herbert Xu wrote:
Andi Kleen [EMAIL PROTECTED] wrote:
My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
textdata bss dec hex filename
3434150 249176 176128 3859454 3ae3fe
Ilpo Järvinen wrote:
On Thu, 16 Aug 2007, Herbert Xu wrote:
We've been through that already. If it's a busy-wait it
should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
Do you (or anyone else for that matter) have an example of this?
The only code I somewhat know, the ieee1394 subsystem, was perhaps
authored and is currently maintained with the expectation that each
occurrence
Ilpo Järvinen wrote:
On Thu, 16 Aug 2007, Herbert Xu wrote:
We've been through that already. If it's a busy-wait it
should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
sk malik wrote:
Solaris 10 people are talkin a lot about the
predictive self healing thing.
Do we have something similar planned/going on for
linux. Or there is no use of this tecnology ;)
Doing this in-kernel would violate the separation of policy and
mechanism. There's nothing wrong with
Anand Jahagirdar wrote:
Hello All
I have searched for Maintainers List to get the correct
Maintainer for my patch. But i am not getting exact maintainer to
which i should forward my patch. Will any body please tell me,to which
maintainer i should forward my patch for its inclusion?
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start removing barriers
Joe Perches wrote:
I've got a tree with a directory full of separate
MAINTAINER blocks that looks like:
00_file_description
3c359_network_driver
3c505_network_driver
3c59x_network_driver
3cr990_network_driver
...
zd1211rw_wireless_driver
zf_machz_watchdog
zr36067_video_for_linux_driver
Linus Torvalds wrote:
So the only reason to add back volatile to the atomic_read() sequence is
not to fix bugs, but to _hide_ the bugs better. They're still there, they
are just a lot harder to trigger, and tend to be a lot subtler.
What about barrier removal? With consistent semantics we
Stefan Richter wrote:
Nick Piggin wrote:
Stefan Richter wrote:
Nick Piggin wrote:
I don't know why people would assume volatile of atomics. AFAIK, most
of the documentation is pretty clear that all the atomic stuff can be
reordered etc. except for those that modify and return a value.
Christoph Lameter wrote:
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten
Herbert Xu wrote:
On Mon, Aug 20, 2007 at 09:15:11AM -0400, Chris Snook wrote:
Linus Torvalds wrote:
So the only reason to add back volatile to the atomic_read() sequence is
not to fix bugs, but to _hide_ the bugs better. They're still there, they
are just a lot harder to trigger, and tend
Anand Jahagirdar wrote:
Hi
As Per the Previous Discussion of my Patch,I think insted of using
KERN_CRIT,it is better to lower the priority level to KERN_WARNING.
thats why i used KERN_WARNING.it will warn administrator and its
administrator responsibility to take whatever action he want to
Joe Perches wrote:
On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
$ show_subsystem drivers/bluetooth/bpa10x.c
BLUETOOTH
what's a subsystem?
I'm not sure there is an appropriate definition.
If there is an appropriate definition, why
should anyone care what subsystem a
David Miller wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
Ie a barrier() is likely _cheaper_ than the code generation downside
from using volatile.
Assuming GCC were ever better about the code generation badness
with volatile that has been
Joe Perches wrote:
On Mon, 2007-08-20 at 15:31 -0400, Chris Snook wrote:
Until I can pass a patch or source file as an argument to a script and get out
the URL of the git tree it needs to go into on the path to Linus's tree,
MAINTAINERS is inadequate. If I ask for the MAINTAINER info
Jan Engelhardt wrote:
Hi,
this more of an informational question. So:
kernel version is 2.6.22.1 on i686
/proc/uptime
9917.81 9140.90 (2h45m)
/proc/cpuinfo:
CPU0
0:282 IO-APIC-edge timer
this is kinda neat, I expected much more interrupts than just 282 since
Jan Engelhardt wrote:
On Aug 6 2007 09:47, Chris Snook wrote:
this more of an informational question. So:
kernel version is 2.6.22.1 on i686
/proc/uptime 9917.81 9140.90 (2h45m)
/proc/cpuinfo:
CPU0
0:282 IO-APIC-edge timer
this is kinda neat, I expected much more
Jerry Jiang wrote:
Is there some feedback on this point ?
Thank you
./Jerry
On Sun, 1 Jul 2007 08:49:37 -0400 (EDT)
Robert P. J. Day [EMAIL PROTECTED] wrote:
prompted by the earlier post on volatiles, is there a reason that
most atomic_t typedefs use volatile int's, while the rest don't?
Chris Friesen wrote:
Chris Snook wrote:
If your architecture doesn't support SMP, the volatile keyword doesn't
do anything except add a useless memory fetch.
I was under the impression that there were other cases as well
(interrupt handlers, for instance) where the value could be modified
Chris Friesen wrote:
Chris Snook wrote:
But if you're not using SMP, the only way you get a race condition is
if your compiler is reordering instructions that have side effects
which are invisible to the compiler. This can happen with MMIO
registers, but it's not an issue with an atomic_t
Chris Friesen wrote:
Chris Snook wrote:
That's why we define atomic_read like so:
#define atomic_read(v) ((v)-counter)
This avoids the aliasing problem, because the compiler must
de-reference the pointer every time, which requires a memory fetch.
Can you guarantee
paul wrote:
Since 2-3 month I have some random data corruption on my Linux server, after
checking disks independently (i'm using raid1on 2 sata disk, the problem is
the same w/o raid) and memory, hardware simce to be out of cause...
Here is my problem:
= head --bytes=300m /dev/urandom test
Zan Lynx wrote:
On Tue, 2007-08-07 at 15:38 -0600, Chris Friesen wrote:
Chris Snook wrote:
That's why we define atomic_read like so:
#define atomic_read(v) ((v)-counter)
This avoids the aliasing problem, because the compiler must de-reference
the pointer every time, which requires
Jerry Jiang wrote:
On Tue, 07 Aug 2007 16:32:23 -0400
Chris Snook [EMAIL PROTECTED] wrote:
It seems like this would fall more into the case of the arch providing
guarantees when using locked/atomic access rather than anything
SMP-related, no?.
But if you're not using SMP, the only way you get
Chris Friesen wrote:
Chris Snook wrote:
This is not a problem, since indirect references will cause the CPU to
fetch the data from memory/cache anyway.
Isn't Zan's sample code (that shows the problem) already using indirect
references?
Yeah, I misinterpreted his conclusion. I thought
Jerry Jiang wrote:
On Wed, 08 Aug 2007 02:47:53 -0400
Chris Snook [EMAIL PROTECTED] wrote:
Chris Friesen wrote:
Chris Snook wrote:
This is not a problem, since indirect references will cause the CPU to
fetch the data from memory/cache anyway.
Isn't Zan's sample code (that shows the problem
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Wed, 8 Aug 2007 11:33:00 +0200
Just saw this while grepping for atomic_reads in a while loops.
Maybe we should re-add the volatile to atomic_t. Not sure.
I think
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 02:31:15PM -0700, Andrew Morton wrote:
On Wed, 08 Aug 2007 17:08:44 -0400
Chris Snook [EMAIL PROTECTED] wrote:
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Wed
From: Chris Snook [EMAIL PROTECTED]
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
can break code that loops
Jesper Juhl wrote:
On 09/08/2007, Chris Snook [EMAIL PROTECTED] wrote:
From: Chris Snook [EMAIL PROTECTED]
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing
Lennert Buytenhek wrote:
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything
Linus Torvalds wrote:
On Wed, 8 Aug 2007, Chris Snook wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
can
Chris Holvenstot wrote:
I think that I may have spotted a minor bug in the 2.6.23 kernel and its
relationship with the EXT3 file system. I apologize in advance if I am
mistaken, reporting a problem that is already known (I did not spot it
in Bugzilla) or if I am reporting it to the wrong forum.
Herbert Xu wrote:
On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote:
If they're not doing anything, sure. Plenty of loops actually do some sort
of real work while waiting for their halt condition, possibly even work
which is necessary for their halt condition to occur, and you
Michael Buesch wrote:
On Thursday 09 August 2007 02:15:33 Andi Kleen wrote:
On Wed, Aug 08, 2007 at 05:08:44PM -0400, Chris Snook wrote:
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Wed, 8 Aug 2007 11:33:00
Robert P. J. Day wrote:
On Wed, 8 Aug 2007, Chris Snook wrote:
Jerry Jiang wrote:
On Wed, 08 Aug 2007 02:47:53 -0400
Chris Snook [EMAIL PROTECTED] wrote:
Chris Friesen wrote:
Chris Snook wrote:
This is not a problem, since indirect references will cause the CPU to
fetch the data from
As recent discussions[1], and bugs[2] have shown, there is a great deal of
confusion about the expected behavior of atomic_read(), compounded by the
fact that it is not the same on all architectures. Since users expect calls
to atomic_read() to actually perform a read, it is not desirable to
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on alpha.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-alpha/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-alpha/atomic.h 2007-08-09 09:19
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on arm.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-arm/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-arm/atomic.h 2007-08-09 06:30:40.0
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on blackfin. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on frv. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on i386, to ensure memory is actually read
each time.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-i386/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-i386
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on h8300. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on ia64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-ia64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-ia64/atomic.h 2007-08-09 06:53
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on m32r.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-m32r/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-m32r/atomic.h 2007-08-09 06:55:53.0
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on avr32.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-avr32/atomic.h2007-08-08
17:48:52.0 -0400
+++ linux-2.6.23-rc2/include/asm-avr32/atomic.h 2007-08-09 06:33:39.0
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on m68knommu. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on m68k. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on mips.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-mips/atomic.h 2007-08-08
17:48:53.0 -0400
+++ linux-2.6.23-rc2/include/asm-mips/atomic.h 2007-08-09 07:02
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on parisc.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-parisc/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-parisc/atomic.h2007-08-09
07:11
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on powerpc.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-powerpc/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-powerpc/atomic.h 2007-08-09
07
From: Chris Snook [EMAIL PROTECTED]
Make atomic[64]_read() volatile on s390, to ensure memory is actually read
each time.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-s390/atomic.h 2007-08-08
17:48:53.0 -0400
+++ linux-2.6.23-rc2/include/asm
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on sh64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sh64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-sh64/atomic.h 2007-08-09 07:22:50.0
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on sh.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sh/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-sh/atomic.h2007-08-09 07:21:33.0
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on sparc64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sparc64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-sparc64/atomic.h 2007-08-09
07
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on sparc.
Leave atomic24_t alone, since it's only used by sparc-specific code.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sparc/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on v850. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() consistent with atomic64_read() and other architectures
on x86_64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-x86_64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on cris.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-cris/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-cris/atomic.h 2007-08-09 06:38:28.0
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on xtensa.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-xtensa/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-xtensa/atomic.h2007-08-09
07:54
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific compiler-induced bugs due to the fact that
atomic_set() used to imply volatile behavior but no longer does.
When we make the
From: Chris Snook [EMAIL PROTECTED]
Update atomic_ops.txt to reflect the newly consistent behavior of
atomic_read(), and to note that volatile (in declarations) is now
considered harmful.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/Documentation/atomic_ops.txt 2007
Arnd Bergmann wrote:
On Thursday 09 August 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable as volatile in
atomic_read
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 10:53:14AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific compiler-induced bugs due to the fact
Segher Boessenkool wrote:
We can't have split stores because we don't use atomic64_t on 32-bit
architectures.
That's not true; the compiler is free to split all stores
(and reads) from memory however it wants. It is debatable
whether volatile would prevent this as well, certainly
it is unsafe
Segher Boessenkool wrote:
Historically this has been
+accomplished by declaring the counter itself to be volatile, but the
+ambiguity of the C standard on the semantics of volatile make this
practice
+vulnerable to overly creative interpretation by compilers.
It's even worse when accessing
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty trick, but the C standard really
does permit this.
Yes, but we don't write code for
Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on frv. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
To head off the criticism, I admit
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 12:36:17PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
If you're depending on volatile writes
being visible to other CPUs, you're screwed either way, because the CPU can
hold that data in cache as long as it wants before it writes
Segher Boessenkool wrote:
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and that
words are aligned unless explicitly packed otherwise, is endemic in
the
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
If you're depending on volatile writes
being visible to other CPUs, you're screwed either
Segher Boessenkool wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty trick, but the C standard really
does permit this.
Yes, but we don't write code for
Geert Uytterhoeven wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
Segher Boessenkool wrote:
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and that
words
Segher Boessenkool wrote:
Explicit
+casting in atomic_read() ensures consistent behavior across
architectures
+and compilers.
Even modulo compiler bugs, what makes you believe that?
When you declare a variable volatile, you don't actually tell the
compiler where you want to override its
Luck, Tony wrote:
+#define atomic_read(v) (*(volatile __s32 *)(v)-counter)
+#define atomic64_read(v) (*(volatile __s64 *)(v)-counter)
#define atomic_set(v,i)(((v)-counter) = (i))
#define atomic64_set(v,i) (((v)-counter) = (i))
Losing the volatile from the
David Howells wrote:
Chris Snook [EMAIL PROTECTED] wrote:
To head off the criticism, I admit this is an oversimplification, and true
busy-waiters should be using cpu_relax(), which contains a barrier.
Why would you want to use cpu_relax()? That's there to waste time efficiently,
isn't
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 03:24:40PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote
Luck, Tony wrote:
Use atomic64_read to read an atomic64_t.
Thanks Andreas!
Chris: This bug is why the 8-byte loads got changed to 4-byte + sign-extend
by your change to atomic_read().
I figured as much. Thanks for confirming this.
With this applied together with shuffling the volatile
Linus Torvalds wrote:
On Fri, 10 Aug 2007, Luck, Tony wrote:
Here are the functions in which they occur in the object file. You
may have to chase down some inlining to find the function that
actually uses atomic_*().
Could you just make the atomic_read() and atomic_set() functions be
inline
Konstantin Kalin wrote:
P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for
these types of Ethernet. But I think it's not right decision because it
would break older revisions of these models.
Any reason you can't distinguish based on PCI ID?
-- Chris
-
To
Andrea Arcangeli wrote:
On Fri, Jul 27, 2007 at 11:43:23PM -0400, Chris Snook wrote:
I'm pretty sure the point of posting a patch that triples CFS performance
on a certain benchmark and arguably improves the semantics of sched_yield
was to improve CFS. You have a point, but it is a point
Al Boldi wrote:
Chris Snook wrote:
Resource size has been outpacing processing latency since the dawn of
time. Disks get bigger much faster than seek times shrink. Main memory
and cache keep growing, while single-threaded processing speed has nearly
ground to a halt.
In the old days, it made
Tong Li wrote:
On Fri, 27 Jul 2007, Chris Snook wrote:
Bill Huey (hui) wrote:
You have to consider the target for this kind of code. There are
applications
where you need something that falls within a constant error bound.
According
to the numbers, the current CFS rebalancing logic doesn't
Tong Li wrote:
Without the global locking, the global synchronization here is simply
ping-ponging a cache line once of while. This doesn't look expensive to
me, but if it does after benchmarking, adjusting sysctl_base_round_slice
can reduce the ping-pong frequency. There might also be a smart
Tim Chen wrote:
On Sat, 2007-07-28 at 02:51 -0400, Chris Snook wrote:
Tim --
Since you're already set up to do this benchmarking, would you mind
varying the parameters a bit and collecting vmstat data? If you want to
run oprofile too, that wouldn't hurt.
Here's the vmstat data
Eduard-Gabriel Munteanu wrote:
*This message was transferred with a trial version of CommuniGate(r) Pro*
Currently, the kernel has the following properties:
1) initramfs can be used to boot the system. We don't need any
predefined /dev entries.
2) udev can be started from the initramfs to
101 - 200 of 488 matches
Mail list logo
