On Fri, Nov 02, 2007 at 04:33:32PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Anyway, if this can make its way to the x86 tree, I think it will get
> > pulled into -mm (?) and get some exposure...
>
> ok, we can certainly try
On Fri, Nov 02, 2007 at 04:33:32PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Anyway, if this can make its way to the x86 tree, I think it will get
pulled into -mm (?) and get some exposure...
ok, we can certainly try it there.
Anything particular I have to do
On Wednesday 07 November 2007 17:19, Andrew Morton wrote:
> > On Tue, 06 Nov 2007 05:08:07 -0500 Chris Snook <[EMAIL PROTECTED]> wrote:
> >
> > Don Porter wrote:
> > > From: Donald E. Porter <[EMAIL PROTECTED]>
> > >
> > > In the bulk page allocation/free routines in mm/page_alloc.c, the zone
> >
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. Symptom: a page allocation failure with order:1,
> GFP_ATOMIC, while there is plenty of memory, as it seems (lots of free
> pages,
On Tuesday 06 November 2007 19:34, Jim van Wel wrote:
> Hi there,
>
> I have a strange problem with like 10-15 servers right now.
> We have here all HP DL380-G5 servers with kernel 2.6.22.6. System all
> works normall. But after a uptime of like 15 a 25 days, we get these
> messages, and the
On Tuesday 06 November 2007 19:34, Jim van Wel wrote:
Hi there,
I have a strange problem with like 10-15 servers right now.
We have here all HP DL380-G5 servers with kernel 2.6.22.6. System all
works normall. But after a uptime of like 15 a 25 days, we get these
messages, and the servers is
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. Symptom: a page allocation failure with order:1,
GFP_ATOMIC, while there is plenty of memory, as it seems (lots of free
pages,
On Wednesday 07 November 2007 17:19, Andrew Morton wrote:
On Tue, 06 Nov 2007 05:08:07 -0500 Chris Snook [EMAIL PROTECTED] wrote:
Don Porter wrote:
From: Donald E. Porter [EMAIL PROTECTED]
In the bulk page allocation/free routines in mm/page_alloc.c, the zone
lock is held across
On Fri, Nov 02, 2007 at 08:56:46PM -0400, Chuck Ebbert wrote:
> On 11/02/2007 07:01 PM, Nick Piggin wrote:
> >
> > In the contended multi-threaded tight loop, the xchg lock is slower than inc
> > lock but still beats the fair xadd lock, but that's only because it is
> >
On Fri, Nov 02, 2007 at 09:51:27AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 2 Nov 2007, Chuck Ebbert wrote:
> >
> > There's also a very easy way to get better fairness with our current
> > spinlocks:
> > use xchg to release the lock instead of mov.
>
> That does nothing at all.
>
> Yes, it
On Fri, Nov 02, 2007 at 10:05:37AM -0400, Rik van Riel wrote:
> On Fri, 2 Nov 2007 07:42:20 +0100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Nov 01, 2007 at 06:19:41PM -0700, Linus Torvalds wrote:
> > >
> > >
> > > On Thu, 1 Nov
On Thu, Nov 01, 2007 at 10:02:04PM -0700, David Miller wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 00:44:25 -0700 (PDT)
>
> > From: Nick Piggin <[EMAIL PROTECTED]>
> > Date: Wed, 31 Oct 2007 08:41:06 +0100
> >
> > > Y
On Thu, Nov 01, 2007 at 10:02:04PM -0700, David Miller wrote:
From: David Miller [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 00:44:25 -0700 (PDT)
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 08:41:06 +0100
You could possibly even do a generic best effort kind of thing
On Fri, Nov 02, 2007 at 10:05:37AM -0400, Rik van Riel wrote:
On Fri, 2 Nov 2007 07:42:20 +0100
Nick Piggin [EMAIL PROTECTED] wrote:
On Thu, Nov 01, 2007 at 06:19:41PM -0700, Linus Torvalds wrote:
On Thu, 1 Nov 2007, Rik van Riel wrote:
Larry Woodman managed to wedge
On Fri, Nov 02, 2007 at 09:51:27AM -0700, Linus Torvalds wrote:
On Fri, 2 Nov 2007, Chuck Ebbert wrote:
There's also a very easy way to get better fairness with our current
spinlocks:
use xchg to release the lock instead of mov.
That does nothing at all.
Yes, it slows the
On Fri, Nov 02, 2007 at 08:56:46PM -0400, Chuck Ebbert wrote:
On 11/02/2007 07:01 PM, Nick Piggin wrote:
In the contended multi-threaded tight loop, the xchg lock is slower than inc
lock but still beats the fair xadd lock, but that's only because it is
just as unfair if not more so
On Thu, Nov 01, 2007 at 06:19:41PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 1 Nov 2007, Rik van Riel wrote:
> >
> > Larry Woodman managed to wedge the VM into a state where, on his
> > 4x dual core system, only 2 cores (on the same CPU) could get the
> > zone->lru_lock overnight. The other 6
On Thu, Nov 01, 2007 at 06:17:42PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 2 Nov 2007, Nick Piggin wrote:
> >
> > But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
> > uses this for inserting breakpoints (but fortunately, a COW page i
On Thu, Nov 01, 2007 at 04:01:45PM -0400, Chuck Ebbert wrote:
> On 11/01/2007 10:03 AM, Nick Piggin wrote:
>
> [edited to show the resulting code]
>
> > + __asm__ __volatile__ (
> > + LOCK_PREFIX "xaddw %w0, %1\n"
> > + &
On Thu, Nov 01, 2007 at 09:08:45AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 1 Nov 2007, Nick Piggin wrote:
> >
> > Untested patch follows
>
> Ok, this looks ok.
>
> Except I would remove the VM_MAYSHARE bit from the test.
But we do want to allow forced CO
On Thu, Nov 01, 2007 at 04:46:36PM +0100, Ingo Molnar wrote:
>
> * Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > > I guess it was done to make the "template" hacks eaiser. I don't
> > > really find that in good taste, especially for important core
> > > infrastructure. Anyway.
> >
> >
On Thu, Nov 01, 2007 at 08:14:47AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 1 Nov 2007, Nick Piggin wrote:
>
> > On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
> > >
> > > We made much bigger changes to ptrace support when we disallowe
On Thu, Nov 01, 2007 at 03:06:05PM +0100, Peter Zijlstra wrote:
> On Thu, 2007-11-01 at 15:02 +0100, Nick Piggin wrote:
>
> > Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
> > decouple it from the spinlock implementation, and make it typesafe (rwloc
Prepare for merging 32 and 64 bit spinlocks, by making them identical
(except for the OOSTORE thing). raw_read_lock and raw_write_lock get a
relaxed register constraint, and 64-bit has a few "=m" constraints changed
to "+m". I hope these things actually make the code better.
Merge spinlock_32.h and spinlock_64.h into spinlock.h.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-x86/spinlock.h
===
--- linux-2.6.orig/include/asm-x86/spinlock.h
+++ linux-2.6/include/a
is to keep
critical sections short, and ensure locks are reasonably fair (which this
patch does).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-x86/spinlock_64.h
===
--- linux-2.6.orig/include/asm-x
do they even get bloated up
with that break_lock then?).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/s
Hi,
I'd like to propose these patches for the x86 tree for a bit more exposure
and testing. Or at least get some discussion going again.
Just for fun I also had a shot at merging the headers, as they become a
lot more similar after this with the removal of the paravirt crud.
Nick
-
To
On Thursday 01 November 2007 22:56, Romano Giannetti wrote:
> Hi,
>
> I have a very possible regression to signal. This morning 2.6.24-rc1
> eat and destroyed my SD card. I have a toshiba laptop with a card slot
> and I have used it with 2.6.23-rcX and 2.6.23 without problems so far.
> This
On Thursday 01 November 2007 20:51, Stefan Richter wrote:
> Nick Piggin wrote:
> > On Thursday 01 November 2007 12:49, Stefan Richter wrote:
> >> fw_device.node_id and fw_device.generation are accessed without mutexes.
> >> We have to ensure that all readers will
On Thursday 01 November 2007 20:51, Stefan Richter wrote:
Nick Piggin wrote:
On Thursday 01 November 2007 12:49, Stefan Richter wrote:
fw_device.node_id and fw_device.generation are accessed without mutexes.
We have to ensure that all readers will get to see node_id updates
before
On Thursday 01 November 2007 22:56, Romano Giannetti wrote:
Hi,
I have a very possible regression to signal. This morning 2.6.24-rc1
eat and destroyed my SD card. I have a toshiba laptop with a card slot
and I have used it with 2.6.23-rcX and 2.6.23 without problems so far.
This
Hi,
I'd like to propose these patches for the x86 tree for a bit more exposure
and testing. Or at least get some discussion going again.
Just for fun I also had a shot at merging the headers, as they become a
lot more similar after this with the removal of the paravirt crud.
Nick
-
To
do they even get bloated up
with that break_lock then?).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
sections short, and ensure locks are reasonably fair (which this
patch does).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-x86/spinlock_64.h
===
--- linux-2.6.orig/include/asm-x86/spinlock_64.h
Prepare for merging 32 and 64 bit spinlocks, by making them identical
(except for the OOSTORE thing). raw_read_lock and raw_write_lock get a
relaxed register constraint, and 64-bit has a few =m constraints changed
to +m. I hope these things actually make the code better.
Signed-off-by: Nick
Merge spinlock_32.h and spinlock_64.h into spinlock.h.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-x86/spinlock.h
===
--- linux-2.6.orig/include/asm-x86/spinlock.h
+++ linux-2.6/include/asm-x86
On Thu, Nov 01, 2007 at 03:06:05PM +0100, Peter Zijlstra wrote:
On Thu, 2007-11-01 at 15:02 +0100, Nick Piggin wrote:
Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
decouple it from the spinlock implementation, and make it typesafe (rwlocks
do not have any
On Thu, Nov 01, 2007 at 08:14:47AM -0700, Linus Torvalds wrote:
On Thu, 1 Nov 2007, Nick Piggin wrote:
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
We made much bigger changes to ptrace support when we disallowed writing
to read-only shared memory areas (we
On Thu, Nov 01, 2007 at 04:46:36PM +0100, Ingo Molnar wrote:
* Lee Schermerhorn [EMAIL PROTECTED] wrote:
I guess it was done to make the template hacks eaiser. I don't
really find that in good taste, especially for important core
infrastructure. Anyway.
Actually, what I
On Thu, Nov 01, 2007 at 04:01:45PM -0400, Chuck Ebbert wrote:
On 11/01/2007 10:03 AM, Nick Piggin wrote:
[edited to show the resulting code]
+ __asm__ __volatile__ (
+ LOCK_PREFIX xaddw %w0, %1\n
+ 1:\t
+ cmpb %h0, %b0\n\t
+ je 2f\n\t
On Thu, Nov 01, 2007 at 09:08:45AM -0700, Linus Torvalds wrote:
On Thu, 1 Nov 2007, Nick Piggin wrote:
Untested patch follows
Ok, this looks ok.
Except I would remove the VM_MAYSHARE bit from the test.
But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
uses
On Thu, Nov 01, 2007 at 06:17:42PM -0700, Linus Torvalds wrote:
On Fri, 2 Nov 2007, Nick Piggin wrote:
But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
uses this for inserting breakpoints (but fortunately, a COW page in a
MAP_PRIVATE mapping is a much more
On Thu, Nov 01, 2007 at 06:19:41PM -0700, Linus Torvalds wrote:
On Thu, 1 Nov 2007, Rik van Riel wrote:
Larry Woodman managed to wedge the VM into a state where, on his
4x dual core system, only 2 cores (on the same CPU) could get the
zone-lru_lock overnight. The other 6 cores on
On Thursday 01 November 2007 12:56, bc Wong (chimwong) wrote:
> Hi,
>
> With 2.6.16 x86_64 on a 4 core machine, I noticed
> that the filp usage (according to /proc/slabinfo)
> shoots up and keeps on increasing sharply when one
> of the CPUs is (1) locked up, or (2) very busy
> doing a lot of
On Thursday 01 November 2007 12:49, Stefan Richter wrote:
> fw_device.node_id and fw_device.generation are accessed without mutexes.
> We have to ensure that all readers will get to see node_id updates
> before generation updates.
>
Hi, a few points:
- can change it to use spinlocks instead?
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > No that would be great. Fingers crossed it won't cause any problems.
>
> I actually doubt it will cause problems.
>
> We made much bigger
On Wed, Oct 31, 2007 at 08:59:41AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > Well the patch is right, in the context of the regression I introduced
> > (and so it should probably go into 2.6.23).
>
> Yeah
On Wed, Oct 31, 2007 at 08:11:10AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > However I actually don't really like how this all works. I don't like that
> > filemap.c should have to know about ptrace, or exactly
On Wednesday 31 October 2007 23:17, Peter Zijlstra wrote:
> On Wed, 2007-10-31 at 21:46 +1100, Nick Piggin wrote:
> > And I'd prevent these ones from doing so.
> >
> > Without keeping track of "reserve" pages, which doesn't feel
> > too clean.
>
>
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote:
> On Wed, 2007-10-31 at 14:51 +1100, Nick Piggin wrote:
> > On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> > > Allow PF_MEMALLOC to be set in softirq context. When running softirqs
> > > from a bo
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote:
> On Wed, 2007-10-31 at 14:37 +1100, Nick Piggin wrote:
> > On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> > > Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
> > >
On Wednesday 31 October 2007 18:41, Nick Piggin wrote:
> On Wednesday 31 October 2007 18:52, Balbir Singh wrote:
> > Reported-by: Nick Piggin <[EMAIL PROTECTED]>
> >
> > The delay incurred in lock_page() should also be accounted in swap delay
> > accounting
&g
On Wednesday 31 October 2007 18:52, Balbir Singh wrote:
> Reported-by: Nick Piggin <[EMAIL PROTECTED]>
>
> The delay incurred in lock_page() should also be accounted in swap delay
> accounting
>
> Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
Ah right, I forgot to
On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 07:42:21 +0100
>
> > Sysrq+T fails to show the stack trace of a running task. Presumably this
> > is to avoid a garbled stack, however it can o
On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 07:42:21 +0100
Sysrq+T fails to show the stack trace of a running task. Presumably this
is to avoid a garbled stack, however it can often be useful, and besides
On Wednesday 31 October 2007 18:52, Balbir Singh wrote:
Reported-by: Nick Piggin [EMAIL PROTECTED]
The delay incurred in lock_page() should also be accounted in swap delay
accounting
Signed-off-by: Balbir Singh [EMAIL PROTECTED]
Ah right, I forgot to resend this one, sorry. Thanks
On Wednesday 31 October 2007 18:41, Nick Piggin wrote:
On Wednesday 31 October 2007 18:52, Balbir Singh wrote:
Reported-by: Nick Piggin [EMAIL PROTECTED]
The delay incurred in lock_page() should also be accounted in swap delay
accounting
Signed-off-by: Balbir Singh [EMAIL PROTECTED
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote:
On Wed, 2007-10-31 at 14:51 +1100, Nick Piggin wrote:
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Allow PF_MEMALLOC to be set in softirq context. When running softirqs
from a borrowed context save current-flags
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote:
On Wed, 2007-10-31 at 14:37 +1100, Nick Piggin wrote:
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
contexts that are entitled to it.
Care
On Wednesday 31 October 2007 23:17, Peter Zijlstra wrote:
On Wed, 2007-10-31 at 21:46 +1100, Nick Piggin wrote:
And I'd prevent these ones from doing so.
Without keeping track of reserve pages, which doesn't feel
too clean.
The problem with that is that once a slab was allocated
On Wed, Oct 31, 2007 at 08:11:10AM -0700, Linus Torvalds wrote:
On Wed, 31 Oct 2007, Nick Piggin wrote:
However I actually don't really like how this all works. I don't like that
filemap.c should have to know about ptrace, or exactly what ptrace wants
here.
It shouldn't
On Wed, Oct 31, 2007 at 08:59:41AM -0700, Linus Torvalds wrote:
On Wed, 31 Oct 2007, Nick Piggin wrote:
Well the patch is right, in the context of the regression I introduced
(and so it should probably go into 2.6.23).
Yeah, it probably is fine for -stable.
And if mine (which
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
On Wed, 31 Oct 2007, Nick Piggin wrote:
No that would be great. Fingers crossed it won't cause any problems.
I actually doubt it will cause problems.
We made much bigger changes to ptrace support when we disallowed
On Thursday 01 November 2007 12:49, Stefan Richter wrote:
fw_device.node_id and fw_device.generation are accessed without mutexes.
We have to ensure that all readers will get to see node_id updates
before generation updates.
Hi, a few points:
- can change it to use spinlocks instead? This
On Thursday 01 November 2007 12:56, bc Wong (chimwong) wrote:
Hi,
With 2.6.16 x86_64 on a 4 core machine, I noticed
that the filp usage (according to /proc/slabinfo)
shoots up and keeps on increasing sharply when one
of the CPUs is (1) locked up, or (2) very busy
doing a lot of printk()'s
on't start running in the middle of
show_stack(). If there are any correctness issues, then the archietcture
would have to take further steps to ensure the task is not running.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index:
On Wednesday 31 October 2007 15:37, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 14:26:32 +1100
>
> > Is it really worth all the added complexity of making swap
> > over NFS files work, given that you could use a network block
&g
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Change ALLOC_NO_WATERMARK page allocation such that the reserves are system
> wide - which they are per setup_per_zone_pages_min(), when we scrape the
> barrel, do it properly.
>
IIRC it's actually not too uncommon to have allocations
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Allow PF_MEMALLOC to be set in softirq context. When running softirqs from
> a borrowed context save current->flags, ksoftirqd will have its own
> task_struct.
What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess
that some
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Provide a method to get the upper bound on the pages needed to allocate
> a given number of objects from a given kmem_cache.
>
Fair enough, but just to make it a bit easier, can you provide a
little reason of why in this patch (or
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Allow the mempool to use the memalloc reserves when all else fails and
> the allocation context would otherwise allow it.
I don't see what this is for. The whole point of when I fixed this
to *not* use the memalloc reserves is because
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
> contexts that are entitled to it.
>
> Care is taken to only touch the SLUB slow path.
>
> This is done to ensure reserve pages don't leak out and get consumed.
I
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
> Hi,
>
> Another posting of the full swap over NFS series.
Hi,
Is it really worth all the added complexity of making swap
over NFS files work, given that you could use a network block
device instead?
Also, have you ensured that
s,
Nick
--
Duane Griffin noticed a 2.6.23 regression that will cause gdb to hang when
it tries to access the memory of another process beyond i_size.
This is because the solution to the fault vs invalidate race requires that
we recheck i_size after the page lock is taken. However in that case, I
had
On Tuesday 30 October 2007 18:54, Lorenzo Allegrucci wrote:
> Hi, sorry if this is a faq but reading
> http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf (slides 17,
> 18)
> looks like 2.6.23 is having a performance regression on MySQL and
> PostgreSQL benchmarks. Has anyone investigated
On Wednesday 31 October 2007 05:32, Christoph Lameter wrote:
> On Tue, 30 Oct 2007, Nick Piggin wrote:
> > Is this actually a speedup on any architecture to roll your own locking
> > rather than using bit spinlock?
>
> It avoids one load from memory when allocating and
On Wednesday 31 October 2007 05:32, Christoph Lameter wrote:
On Tue, 30 Oct 2007, Nick Piggin wrote:
Is this actually a speedup on any architecture to roll your own locking
rather than using bit spinlock?
It avoids one load from memory when allocating and the release is simply
writing
On Tuesday 30 October 2007 18:54, Lorenzo Allegrucci wrote:
Hi, sorry if this is a faq but reading
http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf (slides 17,
18)
looks like 2.6.23 is having a performance regression on MySQL and
PostgreSQL benchmarks. Has anyone investigated these?
requires that
we recheck i_size after the page lock is taken. However in that case, I
had not accounted for the fact that ptracers are granted an exception to this
rule.
Cc: Duane Griffin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/mm
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Hi,
Another posting of the full swap over NFS series.
Hi,
Is it really worth all the added complexity of making swap
over NFS files work, given that you could use a network block
device instead?
Also, have you ensured that
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
contexts that are entitled to it.
Care is taken to only touch the SLUB slow path.
This is done to ensure reserve pages don't leak out and get consumed.
I think
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Allow the mempool to use the memalloc reserves when all else fails and
the allocation context would otherwise allow it.
I don't see what this is for. The whole point of when I fixed this
to *not* use the memalloc reserves is because
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Provide a method to get the upper bound on the pages needed to allocate
a given number of objects from a given kmem_cache.
Fair enough, but just to make it a bit easier, can you provide a
little reason of why in this patch (or reference
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Change ALLOC_NO_WATERMARK page allocation such that the reserves are system
wide - which they are per setup_per_zone_pages_min(), when we scrape the
barrel, do it properly.
IIRC it's actually not too uncommon to have allocations coming
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Allow PF_MEMALLOC to be set in softirq context. When running softirqs from
a borrowed context save current-flags, ksoftirqd will have its own
task_struct.
What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess
that some
On Wednesday 31 October 2007 15:37, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 14:26:32 +1100
Is it really worth all the added complexity of making swap
over NFS files work, given that you could use a network block
device instead?
Don't be misled
of
show_stack(). If there are any correctness issues, then the archietcture
would have to take further steps to ensure the task is not running.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Index: linux-2.6/kernel/sched.c
On Sunday 28 October 2007 14:32, Christoph Lameter wrote:
> Too many troubles with the bitlocks and we really do not need
> to do any bitops. Bitops do not effectively retrieve the old
> value which we want. So use a cmpxchg instead on the arches
> that allow it.
>
> Instead of modifying the
r the
> ramdisk driver. This avoids try_to_free_buffers for ramdisk pages.
I think this is the least intrusive change that is least likely
to break rd, or any other kernel code, that we've seen. It really
should go in 2.6.24, IMO.
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
> Sign
null, don't bother with the truncate check.
>
> Something like this
I think it's a fine minimal patch. Maybe add a comment to say exactly
what we're doing here (pagecache generally just uses !mapping to test
for truncate).
Otherwise, Acked-by: Nick Piggin <[EMAIL PROTECTED]>, thanks!
>
with the truncate check.
Something like this
I think it's a fine minimal patch. Maybe add a comment to say exactly
what we're doing here (pagecache generally just uses !mapping to test
for truncate).
Otherwise, Acked-by: Nick Piggin [EMAIL PROTECTED], thanks!
---
mm/memory.c |4 +++-
1 file
, or any other kernel code, that we've seen. It really
should go in 2.6.24, IMO.
Acked-by: Nick Piggin [EMAIL PROTECTED]
Signed-off-by: Christian Borntraeger [EMAIL PROTECTED]
---
drivers/block/rd.c | 13 +
1 file changed, 13 insertions(+)
Index: linux-2.6/drivers/block/rd.c
On Sunday 28 October 2007 14:32, Christoph Lameter wrote:
Too many troubles with the bitlocks and we really do not need
to do any bitops. Bitops do not effectively retrieve the old
value which we want. So use a cmpxchg instead on the arches
that allow it.
Instead of modifying the page-flags
On Saturday 27 October 2007 15:21, Mike Galbraith wrote:
> Greetings,
>
> For quite a while now, RT kernels have been locking up on me
> occasionally while my back is turned. Yesterday, the little bugger
> finally pounced while my serial console box was up and waiting.
>
> [10138.162953] WARNING:
On Saturday 27 October 2007 15:21, Mike Galbraith wrote:
Greetings,
For quite a while now, RT kernels have been locking up on me
occasionally while my back is turned. Yesterday, the little bugger
finally pounced while my serial console box was up and waiting.
[10138.162953] WARNING: at
On Friday 26 October 2007 13:35, Benjamin Herrenschmidt wrote:
[acks]
Thanks for those...
> > Index: linux-2.6/include/asm-powerpc/mmu_context.h
> > ===
> > --- linux-2.6.orig/include/asm-powerpc/mmu_context.h
> > +++
Hi,
Just out of interest, I did a grep for files containing test_and_set_bit
as well as clear_bit (excluding obvious ones like include/asm-*/bitops.h).
Quite a few interesting things. There is a lot of stuff in drivers/* that
could be suspect, WRT memory barriers, including lots I didn't touch.
On Friday 26 October 2007 09:55, Andi Kleen wrote:
> > But we don't actually know what it is, and it could change with
> > different architectures or versions of gcc. I think the sanest thing
> > is for gcc to help us out here, seeing as there is this very well
> > defined requirement that we
On Friday 26 October 2007 09:09, Andi Kleen wrote:
> On Friday 26 October 2007 00:49:42 Nick Piggin wrote:
> > Marking volatile I think is out of the question. To start with,
> > volatile creates really poor code (and most of the time we actually
> > do want the code
501 - 600 of 3926 matches
Mail list logo
