Krzysztof Oledzki wrote:
On Sat, 30 Jun 2007, Arjan van de Ven wrote:
On Sat, 2007-06-30 at 16:55 +0200, Krzysztof Oledzki wrote:
Hello,
It seems that IRQ handling is somehow different between i386 and x86_64.
In my Dell PowerEdge 1950 is it possible to enable interrupts spreading
over
Anand Jahagirdar wrote:
Hi
consider a case:
if non root user request admin for more number of processes than root
user,admin needs to modify settings in /etc/security/limits.conf file
and if that user is not trustworthy and if does fork bombing attack it
will kill the box.
If root is dumb
Michal Piotrowski wrote:
Hi,
Here is something that might be useful for gamers and audio/video editors
http://www.stardust.webpages.pl/files/tools/deskopt/
You can easily tune CFS/CFQ scheduler params
I would think that gamers and AV editors would want to be using deadline
(or maybe even
James C. Georgas wrote:
I'm not sure I understand how the kernel calculates the amount of
physical RAM it can map during the boot process.
I've quoted two blocks of kernel messages below, one for a kernel with
NOHIGHMEM and another for a kernel with HIGHMEM4G.
If I do the math on the BIOS
James Georgas wrote:
> That's the vmalloc address space. You only get 896 MB in the NORMAL
> zone on i386, to leave room for vmalloc. If you don't like it, go
64-bit.
>
> -- Chris
I like it fine. I just didn't understand it. Thanks for answering.
So, basically, the vmalloc
Xu Yang wrote:
Hello everyone,
Just got a rough question in my head.
don't know whether anyone interested .
mutex vs cache coherency protocol(for multiprocessor)
both of these two can be used to protect shared resource in the memory.
are both of them necessary?
for example:
in a
Justin Piszcz wrote:
Is there anyway to get/see what parameters were passed to a kernel
module? Running modinfo -p will show the defaults, but for
example, st, the scsi tape driver, is there a way to see what it is
currently using? I know in dmesg it shows this when you load it
initially
Chris Snook wrote:
Tong Li wrote:
This patch extends CFS to achieve better fairness for SMPs. For
example, with 10 tasks (same priority) on 8 CPUs, it enables each task
to receive equal CPU time (80%). The code works on top of CFS and
provides SMP fairness at a coarser time grainularity
Tong Li wrote:
On Mon, 23 Jul 2007, Chris Snook wrote:
This patch is massive overkill. Maybe you're not seeing the overhead
on your 8-way box, but I bet we'd see it on a 4096-way NUMA box with a
partially-RT workload. Do you have any data justifying the need for
this patch?
Doing
Aaron Porter wrote:
I'm in the process up upgrading a pool of apache servers from
2.6.17.8 to 2.6.21.5, and we're seeing a pretty major change in behavior.
Under identical network load, 2.6.21 has a load average more than 3 times
higher, cpu 0 spends well over 90% of its time in
Aaron Porter wrote:
On Tue, Jul 24, 2007 at 08:48:00PM +0200, Andi Kleen wrote:
Aaron Porter <[EMAIL PROTECTED]> writes:
I'm in the process up upgrading a pool of apache servers from
2.6.17.8 to 2.6.21.5, and we're seeing a pretty major change in behavior.
Under identical network
Chris Friesen wrote:
Chris Snook wrote:
Concerns aside, I agree that fairness is important, and I'd really
like to see a test case that demonstrates the problem.
One place that might be useful is the case of fairness between resource
groups, where the load balancer needs to consider each
Li, Tong N wrote:
On Tue, 2007-07-24 at 16:39 -0400, Chris Snook wrote:
Divining the intentions of the administrator is an AI-complete problem and we're
not going to try to solve that in the kernel. An intelligent administrator
could also allocate 50% of each CPU to a resource group
Bill Huey (hui) wrote:
On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
Chris Friesen wrote:
We currently use CKRM on an SMP machine, but the only way we can get away
with it is because our main app is affined to one cpu and just about
everything else is affined to the other
Chris Friesen wrote:
Chris Snook wrote:
I don't think Chris's scenario has much bearing on your patch. What
he wants is to have a task that will always be running, but can't
monopolize either CPU. This is useful for certain realtime workloads,
but as I've said before, realtime requires
Chris Friesen wrote:
Ingo Molnar wrote:
the 3s is the problem: change that to 60s! We no way want to
over-migrate for SMP fairness, the change i did gives us reasonable
long-term SMP fairness without the need for high-rate rebalancing.
Actually, I do have requirements from our engineering
Li, Tong N wrote:
On Wed, 2007-07-25 at 16:55 -0400, Chris Snook wrote:
Chris Friesen wrote:
Ingo Molnar wrote:
the 3s is the problem: change that to 60s! We no way want to
over-migrate for SMP fairness, the change i did gives us reasonable
long-term SMP fairness without the need for high
Tong Li wrote:
I'd like to clarify that I'm not trying to push this particular code to
the kernel. I'm a researcher. My intent was to point out that we have a
problem in the scheduler and my dwrr algorithm can potentially help fix
it. The patch itself was merely a proof-of-concept. I'd be
Tong Li wrote:
On Fri, 27 Jul 2007, Chris Snook wrote:
Tong Li wrote:
I'd like to clarify that I'm not trying to push this particular code
to the kernel. I'm a researcher. My intent was to point out that we
have a problem in the scheduler and my dwrr algorithm can potentially
help fix
Tim Chen wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and
Al Boldi wrote:
People wrote:
I believe the users who say their apps really do get paged back in
though, so suspect that's not the case.
Stopping the bush-circumference beating, I do not. -ck (and gentoo) have
this massive Calimero thing going among their users where people are
much less
Bill Huey (hui) wrote:
On Fri, Jul 27, 2007 at 07:36:17PM -0400, Chris Snook wrote:
I don't think that achieving a constant error bound is always a good thing.
We all know that fairness has overhead. If I have 3 threads and 2
processors, and I have a choice between fairly giving each thread
Andrea Arcangeli wrote:
On Fri, Jul 27, 2007 at 08:31:19PM -0400, Chris Snook wrote:
I think Volanomark is being pretty stupid, and deserves to run slowly, but
Indeed, any app doing what volanomark does is pretty inefficient.
But this is not the point. I/O schedulers are pluggable to help
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
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
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 PROTECT
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
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 a
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
an
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, whi
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
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 dat
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
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
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]>
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]>
--- linu
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
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]>
---
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
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
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
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]>
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]>
---
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
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.h
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
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
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
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:
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
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.000
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]>
---
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
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
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-
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/at
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
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
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
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,
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
Paul Mackerras wrote:
Chris Snook writes:
I'll do this for the whole patchset. Stay tuned for the resubmit.
Could you incorporate Segher's patch to turn atomic_{read,set} into
asm on powerpc? Segher claims that using asm is really the only
reliable way to ensure that gcc does what we want
[EMAIL PROTECTED] wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/MAINTAINERS b/MAINTAINERS
index b8bb108..d9d1bcc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -752,6 +752,7 @@ L: [EMAIL PROTECTED]
W:
David Howells wrote:
Chris Snook <[EMAIL PROTECTED]> wrote:
cpu_relax() contains a barrier, so it should do the right thing. For non-smp
architectures, I'm concerned about interacting with interrupt handlers. Some
drivers do use atomic_* operations.
I'm not sure that actually answ
Chris Snook wrote:
[EMAIL PROTECTED] wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/MAINTAINERS b/MAINTAINERS
index b8bb108..d9d1bcc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -752,6 +752,7 @@ L:[EMAIL PROTECTED]
W:
Notably absent is a patch for powerpc. I expect Segher Boessenkool's assembly
implementation should suffice there:
http://lkml.org/lkml/2007/8/10/470
Thanks to all who commented on previous incarnations.
-- Chris Snook
-
To unsubscribe from this list: send the line "unsubscribe
From: Chris Snook <[EMAIL PROTECTED]>
Document proper use of volatile for atomic_t operations.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/Documentation/atomic_ops.txt 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/Documentation/atomic_ops.tx
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on alpha.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-alpha/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-alpha/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on arm.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-arm/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-arm/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on avr32.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-avr32/atomic.h2007-08-13
03:14:13.0 -0400
+++ linux-2.6.23-rc3/include/asm-avr32/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on blackfin.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-blackfin/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-blackfin/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on cris.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-cris/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-cris/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on frv.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-frv/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-frv/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on h8300.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-h8300/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-h8300/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on i386.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-i386/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-i386/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
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
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-ia64/atomic.h 20
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on m32r.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-m32r/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m32r/atomic.h 2007
301 - 400 of 488 matches
Mail list logo
