On Tuesday 20 November 2007 13:02, Christoph Lameter wrote:
> On Mon, 19 Nov 2007, H. Peter Anvin wrote:
> > You're making the assumption here that NUMA = large number of CPUs. This
> > assumption is flat-out wrong.
>
> Well maybe. Usually one gets to NUMA because the hardware gets too big to
> be
On Mon, Nov 19, 2007 at 11:17:48AM -0800, Tim Pepper wrote:
> There is an unmatched parenthesis in the locking commentary of radix_tree.h
> which is trivially fixed by the patch below.
>
> Signed-off-by: Tim Pepper <[EMAIL PROTECTED]>
> Cc: Nick Piggin <[EMAIL PROTECTED]
On Tuesday 20 November 2007 13:02, Christoph Lameter wrote:
> On Mon, 19 Nov 2007, H. Peter Anvin wrote:
> > You're making the assumption here that NUMA = large number of CPUs. This
> > assumption is flat-out wrong.
>
> Well maybe. Usually one gets to NUMA because the hardware gets too big to
> be
On Tuesday 20 November 2007 13:02, Christoph Lameter wrote:
On Mon, 19 Nov 2007, H. Peter Anvin wrote:
You're making the assumption here that NUMA = large number of CPUs. This
assumption is flat-out wrong.
Well maybe. Usually one gets to NUMA because the hardware gets too big to
be
On Mon, Nov 19, 2007 at 11:17:48AM -0800, Tim Pepper wrote:
There is an unmatched parenthesis in the locking commentary of radix_tree.h
which is trivially fixed by the patch below.
Signed-off-by: Tim Pepper [EMAIL PROTECTED]
Cc: Nick Piggin [EMAIL PROTECTED]
Acked-by: Nick Piggin [EMAIL
On Tuesday 20 November 2007 13:02, Christoph Lameter wrote:
On Mon, 19 Nov 2007, H. Peter Anvin wrote:
You're making the assumption here that NUMA = large number of CPUs. This
assumption is flat-out wrong.
Well maybe. Usually one gets to NUMA because the hardware gets too big to
be
On Tuesday 20 November 2007 15:12, Mark Lord wrote:
On 32-bit x86, we have CONFIG_IRQBALANCE available,
but not on 64-bit x86. Why not?
I ask, because this feature seems almost essential to obtaining
reasonable latencies during heavy I/O with fast devices.
My 32-bit Core2Duo MythTV box
On Tuesday 20 November 2007 11:59, Ian Kumlien wrote:
Hi,
I have had this before and sent a mail about it.
It seems like the diskcache is still in use and is never shrunk. This
happened with a odd load though, trackerd started indexing a bit late
and the other workload which is a large
On Tuesday 20 November 2007 15:37, Adrian Bunk wrote:
On Tue, Nov 20, 2007 at 05:29:29AM +0100, Willy Tarreau wrote:
Agreed. When userspace has something to do with the way IRQs are
delivered, it's going to smell as bad as micro-kernels...
The next step to a micro-kernel would then be
Don't know who maintains vt.c, but Antonino's name comes up regularly ;)
--
vt is missing a memory barrier to close the critical section. Use a real
spinlock for this.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/drivers/char/vt.c
On Tuesday 20 November 2007 16:37, Arjan van de Ven wrote:
On Tue, 20 Nov 2007 15:17:15 +1100
For that matter, I'd like to know why it has been decided that the
best place for IRQ balancing is in userspace. It should be in kernel
IMO, and it would probably allow better power saving,
On Tuesday 20 November 2007 16:46, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Unfortunately, we don't show NR_ANON_PAGES in these stats, [...]
sidenote: the way i combat these missing pieces of instrumentation in
the scheduler is to add them immediately to the cfs-debug
On Thursday 15 November 2007 23:48, Ingo Molnar wrote:
> > From: Nick Piggin <[EMAIL PROTECTED]>
> >
> > - if (free_slob_pages.next != prev->next)
> > + if (prev != free_slob_pages.prev &&
> > +
On Thursday 15 November 2007 22:28, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Anyway, I'm really happy to see you're testing and using SLOB upstream
> >
> > :) Is there any particular reason that you're using it?
>
> i sometimes test
're using it?
Thanks,
Nick
Previously, it would be possible for prev->next to point to _slob_pages,
and thus we would try to move a list onto itself, and bad things would
happen.
It seems a bit hairy to be doing list operations with the list marker as an
entry, rather than a head, but...
On Thursday 15 November 2007 19:17, David Brownell wrote:
> On Wednesday 14 November 2007, Nick Piggin wrote:
> > > > > All this does is prevent constant and needless checking for
> > > > > "do you want to preempt me now?" "now?" "now?
On Thursday 15 November 2007 06:19, Nick Piggin wrote:
> On Thursday 15 November 2007 19:17, David Brownell wrote:
> > On Wednesday 14 November 2007, Nick Piggin wrote:
> > > > > > All this does is prevent constant and needless checking for
> > > > > >
On Thursday 15 November 2007 17:28, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > > All this does is prevent constant and needless checking for
> > > "do you want to preempt me now?" "now?" "now?" in "
On Thursday 15 November 2007 17:28, David Brownell wrote:
On Tuesday 13 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now? the
middle now? of now? i/o now? loops.
Actually that's wrong
On Thursday 15 November 2007 06:19, Nick Piggin wrote:
On Thursday 15 November 2007 19:17, David Brownell wrote:
On Wednesday 14 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now
On Thursday 15 November 2007 19:17, David Brownell wrote:
On Wednesday 14 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now? the
middle now? of now? i/o now? loops.
Actually that's
,
and thus we would try to move a list onto itself, and bad things would
happen.
It seems a bit hairy to be doing list operations with the list marker as an
entry, rather than a head, but...
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/mm/slob.c
On Thursday 15 November 2007 22:28, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Anyway, I'm really happy to see you're testing and using SLOB upstream
:) Is there any particular reason that you're using it?
i sometimes test SLOB for -rt, but this time it's the result of my
On Thursday 15 November 2007 23:48, Ingo Molnar wrote:
From: Nick Piggin [EMAIL PROTECTED]
- if (free_slob_pages.next != prev-next)
+ if (prev != free_slob_pages.prev
+ free_slob_pages.next != prev-next)
list_move_tail
On Thursday 15 November 2007 12:11, Herbert Xu wrote:
> On Wed, Nov 14, 2007 at 05:03:25PM -0800, Christoph Lameter wrote:
> > Well this is likely the result of the SLUB regression. If you allocate an
> > order 1 page then the zone locks need to be taken. SLAB queues the a
Yeah, it appears this
On Thursday 15 November 2007 10:46, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 19:48:44 +0800
> > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>
> Applied and I'll queue it up for -stable too.
Good result. Thanks, everyone!
-
To unsubscribe from this
On Thursday 15 November 2007 09:56, Chuck Ebbert wrote:
> On 11/14/2007 05:17 AM, Nick Piggin wrote:
> > But in general, for special files, I guess the response is usually
> > some structured data (that is not visible at the syscall layer).
> > So I don't see a big proble
On Thursday 15 November 2007 08:30, Paul Mackerras wrote:
> Nick Piggin writes:
> > What I really mean is a readv-like syscall, but one that also
> > vectorises the file offset. Maybe this is useful enough as a generic
> > syscall that also helps Paul's example...
>
On Wed, Nov 14, 2007 at 05:18:50PM -0500, Trond Myklebust wrote:
>
> On Wed, 2007-11-14 at 22:50 +0100, Peter Zijlstra wrote:
> > Right, but I guess what Nick asked is, if pages could be stale to start
> > with, how is that avoided in the future.
> >
> > The way I understand it, this re-validate
t; + if ((size + addr) < addr)
> + goto out;
> + if (addr > end - size)
> + goto out;
>
> found:
> area->next = *p;
Yeah I noticed these missing checks when recently working in
this area as well. Weren't sure if I was missing something or
not
On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote:
> Normal locking order is:
>
> i_mutex
> mmap_sem
>
> However NFS's ->mmap hook, which is called under mmap_sem, can take i_mutex.
> Avoid this potential deadlock by doing the work that requires i_mutex from
> the new
On Wednesday 14 November 2007 23:07, David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 23:03:24 +1100
>
> > You're suggesting that the behaviour of a read() should depend on what
> > was in the buffer before the read? Gack! Surely you have better
> > taste
On Wednesday 14 November 2007 22:58, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 10:49:48 +1100
>
> > On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
> > > David Miller writes:
> > > > This is my im
On Wednesday 14 November 2007 22:48, Herbert Xu wrote:
> On Wed, Nov 14, 2007 at 03:10:22AM -0800, David Miller wrote:
> > So the thing that's being effected here in TCP is
> > net/ipv4/tcp.c:select_size(), specifically the else branch:
>
> Thanks for the pointer. Indeed there is a bug in that
On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
> David Miller writes:
> > This is my impression too, all of the things being done with
> > a slew of system calls would be better served by real special
> > files and appropriate fops.
>
> Special files and fops really only work well if
On Wednesday 14 November 2007 22:10, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 09:27:39 +1100
>
> > OK, in vanilla kernels, the page allocator definitely shows higher
> > in the results (than with Herbert's patch reverted).
On Wednesday 14 November 2007 09:27, Nick Piggin wrote:
> > 2) Try removing NETIF_F_SG in drivers/net/loopback.c's dev->feastures
> >setting.
>
> Will try that now.
Doesn't help (with vanilla kernel -- Herbert's patch applied).
data_len histogram drops to 0 and goes t
On Wednesday 14 November 2007 17:37, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> > I'm doing some oprofile runs now to see if I can get any more info.
OK, in vanilla kernels, the page allocator definitely shows higher
in the results (than with Herbert's patch re
On Wednesday 14 November 2007 19:20, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > I mean, if you have a
> > timing critical operation, then you should ensure you have priorities
> > set correctly so that you simply don't get preempted.
>
&g
On Wednesday 14 November 2007 19:37, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > Upstream, all spinlocks prevent preemption.
>
> I chose my wording carefully though. A preemption point is
> more than just a small region where preemption isn't all
On Wednesday 14 November 2007 19:20, David Brownell wrote:
On Tuesday 13 November 2007, Nick Piggin wrote:
I mean, if you have a
timing critical operation, then you should ensure you have priorities
set correctly so that you simply don't get preempted.
Which is why bitops like asm
On Wednesday 14 November 2007 19:37, David Brownell wrote:
On Tuesday 13 November 2007, Nick Piggin wrote:
Upstream, all spinlocks prevent preemption.
I chose my wording carefully though. A preemption point is
more than just a small region where preemption isn't allowed.
It's one
On Wednesday 14 November 2007 17:37, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
I'm doing some oprofile runs now to see if I can get any more info.
OK, in vanilla kernels, the page allocator definitely shows higher
in the results (than with Herbert's patch reverted).
27516
On Wednesday 14 November 2007 09:27, Nick Piggin wrote:
2) Try removing NETIF_F_SG in drivers/net/loopback.c's dev-feastures
setting.
Will try that now.
Doesn't help (with vanilla kernel -- Herbert's patch applied).
data_len histogram drops to 0 and goes to len (I guess that's
On Wednesday 14 November 2007 22:10, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 09:27:39 +1100
OK, in vanilla kernels, the page allocator definitely shows higher
in the results (than with Herbert's patch reverted).
...
I can't see that these numbers
On Wednesday 14 November 2007 22:48, Herbert Xu wrote:
On Wed, Nov 14, 2007 at 03:10:22AM -0800, David Miller wrote:
So the thing that's being effected here in TCP is
net/ipv4/tcp.c:select_size(), specifically the else branch:
Thanks for the pointer. Indeed there is a bug in that area.
On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
David Miller writes:
This is my impression too, all of the things being done with
a slew of system calls would be better served by real special
files and appropriate fops.
Special files and fops really only work well if you can
On Wednesday 14 November 2007 22:58, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 10:49:48 +1100
On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
David Miller writes:
This is my impression too, all of the things being done with
a slew
On Wednesday 14 November 2007 23:07, David Miller wrote:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 23:03:24 +1100
You're suggesting that the behaviour of a read() should depend on what
was in the buffer before the read? Gack! Surely you have better
taste than that?
-next = *p;
Yeah I noticed these missing checks when recently working in
this area as well. Weren't sure if I was missing something or
not.
Acked-by: Nick Piggin [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote:
Normal locking order is:
i_mutex
mmap_sem
However NFS's -mmap hook, which is called under mmap_sem, can take i_mutex.
Avoid this potential deadlock by doing the work that requires i_mutex from
the new -mmap_prepare().
On Wed, Nov 14, 2007 at 05:18:50PM -0500, Trond Myklebust wrote:
On Wed, 2007-11-14 at 22:50 +0100, Peter Zijlstra wrote:
Right, but I guess what Nick asked is, if pages could be stale to start
with, how is that avoided in the future.
The way I understand it, this re-validate is just a
On Thursday 15 November 2007 09:56, Chuck Ebbert wrote:
On 11/14/2007 05:17 AM, Nick Piggin wrote:
But in general, for special files, I guess the response is usually
some structured data (that is not visible at the syscall layer).
So I don't see a big problem to have a similarly arbitrarily
On Thursday 15 November 2007 08:30, Paul Mackerras wrote:
Nick Piggin writes:
What I really mean is a readv-like syscall, but one that also
vectorises the file offset. Maybe this is useful enough as a generic
syscall that also helps Paul's example...
I've sometimes thought it would
On Thursday 15 November 2007 10:46, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 19:48:44 +0800
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Applied and I'll queue it up for -stable too.
Good result. Thanks, everyone!
-
To unsubscribe from this list: send
On Thursday 15 November 2007 12:11, Herbert Xu wrote:
On Wed, Nov 14, 2007 at 05:03:25PM -0800, Christoph Lameter wrote:
Well this is likely the result of the SLUB regression. If you allocate an
order 1 page then the zone locks need to be taken. SLAB queues the a
Yeah, it appears this is
On Wednesday 14 November 2007 17:52, David Brownell wrote:
> On Tuesday 13 November 2007, Andrew Morton wrote:
> > > I'll highlight the
> > > point that such bitops shouldn't be preemption points.
> >
> > Disagree. *everything* should be a preemption point.
>
> So it's wrong that uses the
>
On Wednesday 14 November 2007 17:12, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 04:36:24 +1100
>
> > On Wednesday 14 November 2007 12:58, David Miller wrote:
> > > I suspect the issue is about having a huge skb->data lin
On Wednesday 14 November 2007 10:04, Marc Donner wrote:
> hi
>
> i got this kernel bug on our production system, which is running since last
> saturday.
>
> anybody an idea??
Hugh might be of most help here, cc'ed.
But for the preliminary questions -- Is the bug reproduceable? And
if it is
On Wednesday 14 November 2007 12:58, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Tue, 13 Nov 2007 22:41:58 +1100
>
> > On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
> > > On Sat, 10 Nov 2007, Nick Piggin wrote:
> > &
rant on :) ... These aren't directed specifically at Andrew, but
everyone who merges patches or is involved in the release process.
On Wednesday 14 November 2007 08:04, Andrew Morton wrote:
> On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau
<[EMAIL PROTECTED]> wrote:
> > On Tue, 13 Nov
On Tuesday 13 November 2007 01:30, [EMAIL PROTECTED] wrote:
> From: Martin Schwidefsky <[EMAIL PROTECTED]>
>
> In order to change the layout of the page tables after an mmap has
> crossed the adress space limit of the current page table layout a
> architecture hook in get_unmapped_area is needed.
On Wednesday 14 November 2007 06:22, David Brownell wrote:
> On Tuesday 13 November 2007, Ingo Molnar wrote:
> > * David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > I speculate that either the design has changed (without fanfare),
> > > > > or else that stuff is in RT kernels and has not yet
On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
> On Sat, 10 Nov 2007, Nick Piggin wrote:
> > BTW. your size-2048 kmalloc cache is order-1 in the default setup,
> > wheras kmalloc(1024) or kmalloc(4096) will be order-0 allocations. And
> > SLAB also uses order-0 fo
On Tuesday 13 November 2007 07:13, Matt Mackall wrote:
> On Fri, Nov 09, 2007 at 11:36:56PM +1100, Nick Piggin wrote:
> > Hi,
> >
> > Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
> > core x86 system, with 1 NUMA node per socket. With kernel 2.6.24
On Tuesday 13 November 2007 07:13, Matt Mackall wrote:
On Fri, Nov 09, 2007 at 11:36:56PM +1100, Nick Piggin wrote:
Hi,
Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
core x86 system, with 1 NUMA node per socket. With kernel 2.6.24-rc2,
comparing slab vs slub
On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
On Sat, 10 Nov 2007, Nick Piggin wrote:
BTW. your size-2048 kmalloc cache is order-1 in the default setup,
wheras kmalloc(1024) or kmalloc(4096) will be order-0 allocations. And
SLAB also uses order-0 for size-2048. It would
On Wednesday 14 November 2007 06:22, David Brownell wrote:
On Tuesday 13 November 2007, Ingo Molnar wrote:
* David Brownell [EMAIL PROTECTED] wrote:
I speculate that either the design has changed (without fanfare),
or else that stuff is in RT kernels and has not yet gone upstream.
On Tuesday 13 November 2007 01:30, [EMAIL PROTECTED] wrote:
From: Martin Schwidefsky [EMAIL PROTECTED]
In order to change the layout of the page tables after an mmap has
crossed the adress space limit of the current page table layout a
architecture hook in get_unmapped_area is needed. The
rant on :) ... These aren't directed specifically at Andrew, but
everyone who merges patches or is involved in the release process.
On Wednesday 14 November 2007 08:04, Andrew Morton wrote:
On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau
[EMAIL PROTECTED] wrote:
On Tue, 13 Nov 2007,
On Wednesday 14 November 2007 12:58, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 22:41:58 +1100
On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
On Sat, 10 Nov 2007, Nick Piggin wrote:
BTW. your size-2048 kmalloc cache is order-1
On Wednesday 14 November 2007 10:04, Marc Donner wrote:
hi
i got this kernel bug on our production system, which is running since last
saturday.
anybody an idea??
Hugh might be of most help here, cc'ed.
But for the preliminary questions -- Is the bug reproduceable? And
if it is possible
On Wednesday 14 November 2007 17:12, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 04:36:24 +1100
On Wednesday 14 November 2007 12:58, David Miller wrote:
I suspect the issue is about having a huge skb-data linear area for
TCP sends over loopback. We're
On Wednesday 14 November 2007 17:52, David Brownell wrote:
On Tuesday 13 November 2007, Andrew Morton wrote:
I'll highlight the
point that such bitops shouldn't be preemption points.
Disagree. *everything* should be a preemption point.
So it's wrong that asm-generic/bitops/atomic.h
On Sun, Nov 11, 2007 at 09:04:29PM -0500, Jeff Garzik wrote:
> Nick Piggin wrote:
> >Index: linux-2.6/sound/oss/via82cxxx_audio.c
> >===
> >--- linux-2.6.orig/sound/oss/via82cxxx_audio.c
> >+++ linux-2.6/
d_io.txt
===
--- linux-2.6.orig/Documentation/fb/deferred_io.txt
+++ linux-2.6/Documentation/fb/deferred_io.txt
@@ -7,10 +7,10 @@ IO. The following example may be a usefu
works:
- userspace app like Xfbdev mmaps framebuffer
-- de
-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/mm/vmscan.c
===
--- linux-2.6.orig/mm/vmscan.c
+++ linux-2.6/mm/vmscan.c
@@ -589,7 +589,14 @@ static unsigned long shrink_page_list(st
goto keep_
-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/mm/vmscan.c
===
--- linux-2.6.orig/mm/vmscan.c
+++ linux-2.6/mm/vmscan.c
@@ -589,7 +589,14 @@ static unsigned long shrink_page_list(st
goto keep_locked
: This interface is replaced by vm_ops.fault, but it has been around
- forever, is used by a lot of drivers, and doesn't cost much to
- maintain.
-Who: Nick Piggin [EMAIL PROTECTED]
-
-
What: Interrupt only SA_* flags
When: September 2007
Why: The interrupt related
On Sun, Nov 11, 2007 at 09:04:29PM -0500, Jeff Garzik wrote:
Nick Piggin wrote:
Index: linux-2.6/sound/oss/via82cxxx_audio.c
===
--- linux-2.6.orig/sound/oss/via82cxxx_audio.c
+++ linux-2.6/sound/oss/via82cxxx_audio.c
@@ -2099,8
On Saturday 10 November 2007 18:54, Sam Ravnborg wrote:
> On Fri, Nov 09, 2007 at 10:23:23PM -0500, Jeff Garzik wrote:
> > Sam Ravnborg wrote:
> > >This is the patch that get rid of ARCH=i386 and ARCH=x86_64
> > >and introduce ARCH=x86.
> > >It touches several files but the changes are all one or
On Saturday 10 November 2007 18:54, Sam Ravnborg wrote:
On Fri, Nov 09, 2007 at 10:23:23PM -0500, Jeff Garzik wrote:
Sam Ravnborg wrote:
This is the patch that get rid of ARCH=i386 and ARCH=x86_64
and introduce ARCH=x86.
It touches several files but the changes are all one or two-liners.
On Saturday 10 November 2007 12:29, Nick Piggin wrote:
> cc'ed linux-netdev
Err, make that 'netdev' :P
> On Saturday 10 November 2007 10:46, Christoph Lameter wrote:
> > commit deea84b0ae3d26b41502ae0a39fe7fe134e703d0 seems to cause a drop
> > in SLUB tbench performance:
> &
can't do
non-atomic access. Split this into add_to_page_cache_locked, for tmpfs.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -
fs: rename buffer trylock
Converting the buffer lock to new bitops also requires name change, so convert
the raw test_and_set bitop to a trylock.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
fs/buffer.c |4 ++--
fs/jbd/commit.c |2 +-
fs/jbd2/co
=> trylock_page, SetPageLocked => set_page_locked).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
drivers/scsi/sg.c |2 +-
fs/afs/write.c |2 +-
fs/cifs/file.c |2 +-
fs/jbd/commit.c |2 +-
fs/jbd2/commit.c|
cc'ed linux-netdev
On Saturday 10 November 2007 10:46, Christoph Lameter wrote:
> commit deea84b0ae3d26b41502ae0a39fe7fe134e703d0 seems to cause a drop
> in SLUB tbench performance:
>
> 8p x86_64 system:
>
> 2.6.24-rc2:
> 1260.80 MB/sec
>
> After reverting the patch:
> 2350.04 MB/sec
On Saturday 10 November 2007 07:52, Benjamin Herrenschmidt wrote:
> > diff -urpNa -X dontdiff linux-2.6.23.1-rt4/arch/powerpc/kernel/process.c
> > linux-2.6.23.1-rt4-fix/arch/powerpc/kernel/process.c ---
> > linux-2.6.23.1-rt4/arch/powerpc/kernel/process.c2007-10-12
> > 09:43:44.0
On Thursday 08 November 2007 15:37, Gregory Haskins wrote:
> Peter Zijlstra wrote:
> > Bah, missed a hunk
> >
> > ---
> > Subject: sched: avoid large irq-latencies in smp-balancing
> >
> > SMP balancing is done with IRQs disabled and can iterate the full rq.
> > When rqs are large this can cause
Hi,
Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
core x86 system, with 1 NUMA node per socket. With kernel 2.6.24-rc2,
comparing slab vs slub allocators.
I run from 1 to 16 client threads, 5 times each, and restarting
the tbench server between every run. I'm just taking the
On Saturday 10 November 2007 07:52, Benjamin Herrenschmidt wrote:
diff -urpNa -X dontdiff linux-2.6.23.1-rt4/arch/powerpc/kernel/process.c
linux-2.6.23.1-rt4-fix/arch/powerpc/kernel/process.c ---
linux-2.6.23.1-rt4/arch/powerpc/kernel/process.c2007-10-12
09:43:44.0 -0700 +++
cc'ed linux-netdev
On Saturday 10 November 2007 10:46, Christoph Lameter wrote:
commit deea84b0ae3d26b41502ae0a39fe7fe134e703d0 seems to cause a drop
in SLUB tbench performance:
8p x86_64 system:
2.6.24-rc2:
1260.80 MB/sec
After reverting the patch:
2350.04 MB/sec
SLAB
= trylock_page, SetPageLocked = set_page_locked).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
drivers/scsi/sg.c |2 +-
fs/afs/write.c |2 +-
fs/cifs/file.c |2 +-
fs/jbd/commit.c |2 +-
fs/jbd2/commit.c|2 +-
fs/reiserfs
fs: rename buffer trylock
Converting the buffer lock to new bitops also requires name change, so convert
the raw test_and_set bitop to a trylock.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
fs/buffer.c |4 ++--
fs/jbd/commit.c |2 +-
fs/jbd2/commit.c
can't do
non-atomic access. Split this into add_to_page_cache_locked, for tmpfs.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -426,29
On Saturday 10 November 2007 12:29, Nick Piggin wrote:
cc'ed linux-netdev
Err, make that 'netdev' :P
On Saturday 10 November 2007 10:46, Christoph Lameter wrote:
commit deea84b0ae3d26b41502ae0a39fe7fe134e703d0 seems to cause a drop
in SLUB tbench performance:
8p x86_64 system
Hi,
Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
core x86 system, with 1 NUMA node per socket. With kernel 2.6.24-rc2,
comparing slab vs slub allocators.
I run from 1 to 16 client threads, 5 times each, and restarting
the tbench server between every run. I'm just taking the
On Thursday 08 November 2007 15:37, Gregory Haskins wrote:
Peter Zijlstra wrote:
Bah, missed a hunk
---
Subject: sched: avoid large irq-latencies in smp-balancing
SMP balancing is done with IRQs disabled and can iterate the full rq.
When rqs are large this can cause large
On Thursday 08 November 2007 00:48, Frank van Maarseveen wrote:
> On Wed, Nov 07, 2007 at 09:01:17AM +1100, Nick Piggin wrote:
> > On Tuesday 06 November 2007 04:42, Frank van Maarseveen wrote:
> > > For quite some time I'm seeing occasional lockups spread over 50
> >
On Thursday 08 November 2007 00:48, Frank van Maarseveen wrote:
On Wed, Nov 07, 2007 at 09:01:17AM +1100, Nick Piggin wrote:
On Tuesday 06 November 2007 04:42, Frank van Maarseveen wrote:
For quite some time I'm seeing occasional lockups spread over 50
different machines I'm maintaining
401 - 500 of 3926 matches
Mail list logo
