On Sat, Sep 29, 2007 at 08:16:47PM -0700, Paul E. McKenney wrote:
On Sat, Sep 29, 2007 at 03:28:48PM +0200, Nick Piggin wrote:
Acked-by: Paul E. McKenney [EMAIL PROTECTED]
Thanks v much for confirming, everyone.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6
On Sat, Sep 29, 2007 at 12:12:52PM -0700, Davide Libenzi wrote:
On Sat, 29 Sep 2007, Nick Piggin wrote:
[ This is true for x86's sfence/lfence, but raises a question about Linux's
memory barriers. Does anybody expect that a sequence of smp_wmb and smp_rmb
would ever provide a full smp_mb
On Sat, Sep 29, 2007 at 09:07:30AM -0700, Linus Torvalds wrote:
On Sat, 29 Sep 2007, Nick Piggin wrote:
The non-temporal stores should be basically considered to be IO, not
any
normal memory operation.
Maybe you're thinking of uncached / WC? Non-temporal stores
On Monday 01 October 2007 04:07, Paul Jackson wrote:
Nick wrote:
The user should just be able to specify exactly the partitioning of
tasks required, and cpusets should ask the scheduler to do the best
job of load balancing possible.
If the cpusets which have 'sched_load_balance' enabled
On Monday 01 October 2007 06:12, Andrew Morton wrote:
On Sun, 30 Sep 2007 05:09:28 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
On Sunday 30 September 2007 05:20, Andrew Morton wrote:
We can't run out of unfragmented memory for an order-2 GFP_KERNEL
allocation in this workload. We go
Hi Denys, thanks for reporting (btw. please reply-to-all when replying
on lkml).
You say that SLAB is better than SLUB on an otherwise identical kernel,
but I didn't see if you quantified the actual numbers? It sounds like there
is still a regression with SLAB?
On Monday 01 October 2007 03:48,
would ever provide a full smp_mb barrier? I've always assumed no, but I
don't know if it is actually documented? ]
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-i386/system.h
===
--- linux-2.6.
On Fri, Sep 28, 2007 at 06:18:31PM +0100, Alan Cox wrote:
> > on the broken ppro stores config option if you just tell me what should
> > be there (again, remember that my patch isn't actually changing anything
> > already there except for smp_rmb side).
>
> The PPro needs rmb to ensure a store
On Fri, Sep 28, 2007 at 09:15:06AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 28 Sep 2007, Alan Cox wrote:
> >
> > However
> > - You've not shown the patch has any performance gain
>
> It would be nice to see this.
Actually, in a userspace test I have (which actually does enough
work to
On Saturday 29 September 2007 03:57, Mathieu Desnoyers wrote:
> Isn't the actual instrumentation present in the VM subsystem consisting
> mostly of event counters ? This kind of profiling provides limited help in
> following specific delays in the kernel. Martin Bligh's paper "Linux
> Kernel
On Saturday 29 September 2007 04:41, Christoph Lameter wrote:
> On Fri, 28 Sep 2007, Peter Zijlstra wrote:
> > memory got massively fragemented, as anti-frag gets easily defeated.
> > setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
> > order blocks to stay available, so we
On Saturday 29 September 2007 19:27, Andrew Morton wrote:
> On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra <[EMAIL PROTECTED]>
wrote:
> > > oom-killings, or page allocation failures? The latter, one hopes.
> >
> > Linux version 2.6.23-rc4-mm1-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2
> >
On Monday 24 September 2007 18:45, Peter Zijlstra wrote:
> Just an idea I had, it seems like a good idea to wait for RCU callbacks
> in reclaim so that we won't get all of memory stuck there.
I think it would be much too aggressive (_especially_ with preemptible
RCU, I would have thought?). And
On Friday 28 September 2007 18:42, Krzysztof Oledzki wrote:
> Hello,
>
> I am experiencing weird system hangs. Once about 2-5 weeks system freezes
> and stops accepting remote connections, so it is no longer possible to
> connect to most important services: smtp (postfix), www (squid) or even
>
On Friday 28 September 2007 00:42, Jarek Poplawski wrote:
> On Thu, Sep 27, 2007 at 03:31:23PM +0200, Ingo Molnar wrote:
> > * Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> ...
>
> > > OK, but let's forget about fixing iperf. Probably I got this wrong,
> > > but I've thought this "bad" iperf
On Friday 28 September 2007 00:42, Jarek Poplawski wrote:
On Thu, Sep 27, 2007 at 03:31:23PM +0200, Ingo Molnar wrote:
* Jarek Poplawski [EMAIL PROTECTED] wrote:
...
OK, but let's forget about fixing iperf. Probably I got this wrong,
but I've thought this bad iperf patch was tested on
On Monday 24 September 2007 18:45, Peter Zijlstra wrote:
Just an idea I had, it seems like a good idea to wait for RCU callbacks
in reclaim so that we won't get all of memory stuck there.
I think it would be much too aggressive (_especially_ with preemptible
RCU, I would have thought?). And not
On Friday 28 September 2007 18:42, Krzysztof Oledzki wrote:
Hello,
I am experiencing weird system hangs. Once about 2-5 weeks system freezes
and stops accepting remote connections, so it is no longer possible to
connect to most important services: smtp (postfix), www (squid) or even
ssh.
On Saturday 29 September 2007 19:27, Andrew Morton wrote:
On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra [EMAIL PROTECTED]
wrote:
oom-killings, or page allocation failures? The latter, one hopes.
Linux version 2.6.23-rc4-mm1-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2
(Ubuntu
On Saturday 29 September 2007 04:41, Christoph Lameter wrote:
On Fri, 28 Sep 2007, Peter Zijlstra wrote:
memory got massively fragemented, as anti-frag gets easily defeated.
setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
order blocks to stay available, so we don't
On Saturday 29 September 2007 03:57, Mathieu Desnoyers wrote:
Isn't the actual instrumentation present in the VM subsystem consisting
mostly of event counters ? This kind of profiling provides limited help in
following specific delays in the kernel. Martin Bligh's paper Linux
Kernel Debugging
On Fri, Sep 28, 2007 at 09:15:06AM -0700, Linus Torvalds wrote:
On Fri, 28 Sep 2007, Alan Cox wrote:
However
- You've not shown the patch has any performance gain
It would be nice to see this.
Actually, in a userspace test I have (which actually does enough
work to trigger out of
On Fri, Sep 28, 2007 at 06:18:31PM +0100, Alan Cox wrote:
on the broken ppro stores config option if you just tell me what should
be there (again, remember that my patch isn't actually changing anything
already there except for smp_rmb side).
The PPro needs rmb to ensure a store doesn't
provide a full smp_mb barrier? I've always assumed no, but I
don't know if it is actually documented? ]
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-i386/system.h
===
--- linux-2.6.orig/include/asm
On Saturday 29 September 2007 03:15, Sergey Popov wrote:
> Short description: after recompiling 32-bit kernel with 64Gb highmem
> support and rebooting into it, OS started working very much slower
> then before.
>
> Specifications: Intel Core 2 Duo [EMAIL PROTECTED],4Ghz on Intel i965Q-based
>
On Saturday 29 September 2007 03:33, Christoph Lameter wrote:
> On Fri, 28 Sep 2007, Nick Piggin wrote:
> > On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> > > SLAB_VFALLBACK can be specified for selected slab caches. If fallback
> > > is available the
On Friday 28 September 2007 17:42, Peter Zijlstra wrote:
> Replace raw TestSetPageLocked() usage with trylock_page()
I have such a thing queued too, for the lock bitops patches for when 2.6.24
opens, Andrew promises me :).
I guess they should be identical, except I don't like doing trylock_page
On Thursday 20 September 2007 11:38, David Chinner wrote:
> On Wed, Sep 19, 2007 at 04:04:30PM +0200, Andrea Arcangeli wrote:
> > Plus of course you don't like fsblock because it requires work to
> > adapt a fs to it, I can't argue about that.
>
> No, I don't like fsblock because it is inherently
On Fri, Sep 28, 2007 at 05:07:19PM +0100, Alan Cox wrote:
> > The only alternative is to assume a weak memory model, and add the required
> > barriers to spin_unlock -- something that has been explicitly avoided, but
>
> We have the barriers in spin_unlock already for Pentium Pro and IDT
>
On Saturday 29 September 2007 02:23, Mathieu Desnoyers wrote:
> * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > This is a pretty major bugfix.
> > >
> > > GFP_NOIO and GFP_NOFS callers should have been spending really large
> > > amounts of time stuck
On Saturday 29 September 2007 00:34, Linus Torvalds wrote:
> On Fri, 28 Sep 2007, Nick Piggin wrote:
> > > God I hate select.
> >
> > IMO a better implementation would result in a notification / confirmation
> > of turning on new items, and the ability to desele
ostores do SMP? If not, then smp_wmb
can also be a simple barrier on i386 too.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-i386/system.h
===
--- linux-2.6.orig/include/asm-i386/system.h
+++ l
On Friday 28 September 2007 18:02, Ingo Molnar wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > This is a pretty major bugfix.
> >
> > GFP_NOIO and GFP_NOFS callers should have been spending really large
> > amounts of time stuck in that sleep.
> >
> > I wonder why nobody noticed this
On Thursday 27 September 2007 11:50, Fengguang Wu wrote:
> We don't want to introduce pointless delays in throttle_vm_writeout()
> when the writeback limits are not yet exceeded, do we?
I don't think so (ie. I agree with you).
IIRC, Marcelo initially did the throttle_vm_writeout?
>
On Wednesday 26 September 2007 21:57, Ric Wheeler wrote:
> Bob Bell wrote:
> > On Sat, Sep 01, 2007 at 08:43:49PM -0600, Matthew Wilcox wrote:
> >> Here's the second version of TASK_KILLABLE. A few changes since
> >> version 1:
> >
> >
> >
> >> I obviously haven't covered every place that can
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
> available then the conservative settings for higher order allocations are
> overridden. We then request an order that can accomodate at mininum
> 100 objects.
On Sunday 02 September 2007 08:14, Andi Kleen wrote:
> David Miller <[EMAIL PROTECTED]> writes:
> > From: Byron Bradley <[EMAIL PROTECTED]>
> > Date: Fri, 31 Aug 2007 03:12:46 + (UTC)
> >
> > > Anybody got any ideas of how we fix this?
> >
> > I don't know how much testing XFS gets on ARM, but
On Thursday 20 September 2007 16:31, Andrew Morton wrote:
> I struggled for five minutes trying to work out how to make CONFIG_SYSCTL
> go away and gave up in disgust.
>
> God I hate select.
IMO a better implementation would result in a notification / confirmation of
turning on new items, and
On Thursday 20 September 2007 16:56, Dag Nygren wrote:
> Hi,
>
> I have the kview zoom function mapped to the scrollwheel
> with ctrl.
> Now my wife found out and watching our photos wanted
> to zoom out a bit. Then she just rotated the scrollwheel a lot
> and expected the zoom to happen. What did
On Sunday 02 September 2007 08:14, Andi Kleen wrote:
David Miller [EMAIL PROTECTED] writes:
From: Byron Bradley [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 03:12:46 + (UTC)
Anybody got any ideas of how we fix this?
I don't know how much testing XFS gets on ARM, but one thing that
On Thursday 27 September 2007 11:50, Fengguang Wu wrote:
We don't want to introduce pointless delays in throttle_vm_writeout()
when the writeback limits are not yet exceeded, do we?
I don't think so (ie. I agree with you).
IIRC, Marcelo initially did the throttle_vm_writeout?
Cc: Nick Piggin
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order that can accomodate at mininum
100 objects. The
On Thursday 20 September 2007 16:31, Andrew Morton wrote:
I struggled for five minutes trying to work out how to make CONFIG_SYSCTL
go away and gave up in disgust.
God I hate select.
IMO a better implementation would result in a notification / confirmation of
turning on new items, and the
On Thursday 20 September 2007 16:56, Dag Nygren wrote:
Hi,
I have the kview zoom function mapped to the scrollwheel
with ctrl.
Now my wife found out and watching our photos wanted
to zoom out a bit. Then she just rotated the scrollwheel a lot
and expected the zoom to happen. What did happen
On Wednesday 26 September 2007 21:57, Ric Wheeler wrote:
Bob Bell wrote:
On Sat, Sep 01, 2007 at 08:43:49PM -0600, Matthew Wilcox wrote:
Here's the second version of TASK_KILLABLE. A few changes since
version 1:
snip
I obviously haven't covered every place that can result in a
? If not, then smp_wmb
can also be a simple barrier on i386 too.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-i386/system.h
===
--- linux-2.6.orig/include/asm-i386/system.h
+++ linux-2.6/include/asm
On Friday 28 September 2007 18:02, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
This is a pretty major bugfix.
GFP_NOIO and GFP_NOFS callers should have been spending really large
amounts of time stuck in that sleep.
I wonder why nobody noticed this happening. Either
On Fri, Sep 28, 2007 at 05:07:19PM +0100, Alan Cox wrote:
The only alternative is to assume a weak memory model, and add the required
barriers to spin_unlock -- something that has been explicitly avoided, but
We have the barriers in spin_unlock already for Pentium Pro and IDT
Winchip
On Saturday 29 September 2007 02:23, Mathieu Desnoyers wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
This is a pretty major bugfix.
GFP_NOIO and GFP_NOFS callers should have been spending really large
amounts of time stuck in that sleep.
On Saturday 29 September 2007 00:34, Linus Torvalds wrote:
On Fri, 28 Sep 2007, Nick Piggin wrote:
God I hate select.
IMO a better implementation would result in a notification / confirmation
of turning on new items, and the ability to deselect options which will
also confirm
On Thursday 20 September 2007 11:38, David Chinner wrote:
On Wed, Sep 19, 2007 at 04:04:30PM +0200, Andrea Arcangeli wrote:
Plus of course you don't like fsblock because it requires work to
adapt a fs to it, I can't argue about that.
No, I don't like fsblock because it is inherently a
On Friday 28 September 2007 17:42, Peter Zijlstra wrote:
Replace raw TestSetPageLocked() usage with trylock_page()
I have such a thing queued too, for the lock bitops patches for when 2.6.24
opens, Andrew promises me :).
I guess they should be identical, except I don't like doing trylock_page
On Saturday 29 September 2007 03:15, Sergey Popov wrote:
Short description: after recompiling 32-bit kernel with 64Gb highmem
support and rebooting into it, OS started working very much slower
then before.
Specifications: Intel Core 2 Duo [EMAIL PROTECTED],4Ghz on Intel i965Q-based
On Saturday 29 September 2007 03:33, Christoph Lameter wrote:
On Fri, 28 Sep 2007, Nick Piggin wrote:
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
SLAB_VFALLBACK can be specified for selected slab caches. If fallback
is available then the conservative settings for higher
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> If we are in an interrupt context then simply defer the free via a
> workqueue.
>
> In an interrupt context it is not possible to use vmalloc_addr() to
> determine the vmalloc address. So add a variant that does that too.
>
>
On Wednesday 19 September 2007 04:30, Linus Torvalds wrote:
> On Tue, 18 Sep 2007, Nick Piggin wrote:
> > ROFL! Yeah of course, how could I have forgotten about our trusty OOM
> > killer as the solution to the fragmentation problem? It would only have
> > been funnier if y
On Wednesday 19 September 2007 04:30, Linus Torvalds wrote:
On Tue, 18 Sep 2007, Nick Piggin wrote:
ROFL! Yeah of course, how could I have forgotten about our trusty OOM
killer as the solution to the fragmentation problem? It would only have
been funnier if you had said to reboot every so
On Wednesday 19 September 2007 03:44, Andrew Morton wrote:
> On Tue, 18 Sep 2007 11:29:50 +1000 Nick Piggin <[EMAIL PROTECTED]>
wrote:
> > It would be interesting to test -mm kernels. They have a patch which
> > reduces zone lock contention quite a lot.
>
> They d
On Tuesday 18 September 2007 20:41, Hisashi Hifumi wrote:
> I modified my patch based on your comment.
>
> At 11:37 07/09/14, Andrew Morton wrote:
> >So I do think that for safety and sanity's sake, we should be taking a
> > ref on the pages when they are in a pagevec. That's going to hurt your
On Tuesday 18 September 2007 08:21, Christoph Lameter wrote:
> On Sun, 16 Sep 2007, Nick Piggin wrote:
> > > > So if you argue that vmap is a downside, then please tell me how you
> > > > consider the -ENOMEM of your approach to be better?
> > >
> > >
On Tuesday 18 September 2007 08:00, Christoph Lameter wrote:
> On Sun, 16 Sep 2007, Nick Piggin wrote:
> > I don't know how it would prevent fragmentation from building up
> > anyway. It's commonly the case that potentially unmovable objects
> > are allowed to fill up all of
On Tuesday 18 September 2007 08:05, Christoph Lameter wrote:
> On Sun, 16 Sep 2007, Nick Piggin wrote:
> > > > fsblock doesn't need any of those hacks, of course.
> > >
> > > Nor does mine for the low orders that we are considering. For order >
> > >
On Tuesday 18 September 2007 04:19, Avi Kivity wrote:
> Nick Piggin wrote:
> >> I should mention that the converting to use ->fault() is a 15-minute
> >> change; the tricky part is adding backwards compatibility for the
> >> external module package.
> >
&g
On Tuesday 18 September 2007 03:04, Rik van Riel wrote:
> Nick Piggin wrote:
> > (Rik has a patch sitting in -mm I believe which would make this problem
> > even worse, by doing even less highmem scanning in response to lowmem
> > allocations).
>
> My patch should n
On Tuesday 18 September 2007 03:04, Rik van Riel wrote:
Nick Piggin wrote:
(Rik has a patch sitting in -mm I believe which would make this problem
even worse, by doing even less highmem scanning in response to lowmem
allocations).
My patch should not make any difference here, since
On Tuesday 18 September 2007 04:19, Avi Kivity wrote:
Nick Piggin wrote:
I should mention that the converting to use -fault() is a 15-minute
change; the tricky part is adding backwards compatibility for the
external module package.
It should be mostly possible to ifdef a nopage
On Tuesday 18 September 2007 08:05, Christoph Lameter wrote:
On Sun, 16 Sep 2007, Nick Piggin wrote:
fsblock doesn't need any of those hacks, of course.
Nor does mine for the low orders that we are considering. For order
MAX_ORDER this is unavoidable since the page allocator cannot
On Tuesday 18 September 2007 08:00, Christoph Lameter wrote:
On Sun, 16 Sep 2007, Nick Piggin wrote:
I don't know how it would prevent fragmentation from building up
anyway. It's commonly the case that potentially unmovable objects
are allowed to fill up all of ram (dentries, inodes, etc
On Tuesday 18 September 2007 20:41, Hisashi Hifumi wrote:
I modified my patch based on your comment.
At 11:37 07/09/14, Andrew Morton wrote:
So I do think that for safety and sanity's sake, we should be taking a
ref on the pages when they are in a pagevec. That's going to hurt your
On Tuesday 18 September 2007 08:21, Christoph Lameter wrote:
On Sun, 16 Sep 2007, Nick Piggin wrote:
So if you argue that vmap is a downside, then please tell me how you
consider the -ENOMEM of your approach to be better?
That is again pretty undifferentiated. Are we talking about
On Wednesday 19 September 2007 03:44, Andrew Morton wrote:
On Tue, 18 Sep 2007 11:29:50 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
It would be interesting to test -mm kernels. They have a patch which
reduces zone lock contention quite a lot.
They do? Which patch?
Hmm... mm-buffered-write
On Tuesday 18 September 2007 00:09, Anton Altaparmakov wrote:
> On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote:
> > On 15 Sep 2007, at 11:52, Andrew Morton wrote:
> >> On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra
> >>
> >> <[EMAIL PROTECTED]> wrote:
> >>> Anyway, looks like all of
On Monday 17 September 2007 19:18, Avi Kivity wrote:
> Avi Kivity wrote:
> > Christoph Hellwig wrote:
> >> On Mon, Sep 17, 2007 at 10:30:43AM +0200, Avi Kivity wrote:
> >>> From: Nguyen Anh Quynh <[EMAIL PROTECTED]>
> >>>
> >>> *nopage() in kvm_main.c should only store the type of mmap() fault if
On Monday 17 September 2007 14:07, David Chinner wrote:
> On Fri, Sep 14, 2007 at 06:48:55AM +1000, Nick Piggin wrote:
> > OK, the vunmap batching code wipes your TLB flushing and IPIs off
> > the table. Diffstat below, but the TLB portions are here (besides that
> > _ev
On Saturday 15 September 2007 04:08, Christoph Lameter wrote:
> On Fri, 14 Sep 2007, Nick Piggin wrote:
> > However fsblock can do everything that higher order pagecache can
> > do in terms of avoiding vmap and giving contiguous memory to block
> > devices by opportunistica
On Monday 17 September 2007 04:13, Mel Gorman wrote:
> On (15/09/07 14:14), Goswin von Brederlow didst pronounce:
> > I keep coming back to the fact that movable objects should be moved
> > out of the way for unmovable ones. Anything else just allows
> > fragmentation to build up.
>
> This is
On Saturday 15 September 2007 20:22, Soeren Sonnenburg wrote:
> On Sat, 2007-09-15 at 09:47 +, Soeren Sonnenburg wrote:
> > Memtest did not find anything after 16 passes so I finally stopped it
> > applied your patch and used
> >
> > CONFIG_DEBUG_SLAB=y
> > CONFIG_DEBUG_SLAB_LEAK=y
> >
> >
On Saturday 15 September 2007 03:52, Christoph Lameter wrote:
> On Fri, 14 Sep 2007, Nick Piggin wrote:
> > > > [*] ok, this isn't quite true because if you can actually put a hard
> > > > limit on unmovable allocations then anti-frag will fundamentally help
> > &
On Saturday 15 September 2007 20:22, Soeren Sonnenburg wrote:
On Sat, 2007-09-15 at 09:47 +, Soeren Sonnenburg wrote:
Memtest did not find anything after 16 passes so I finally stopped it
applied your patch and used
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
and booted into
On Saturday 15 September 2007 03:52, Christoph Lameter wrote:
On Fri, 14 Sep 2007, Nick Piggin wrote:
[*] ok, this isn't quite true because if you can actually put a hard
limit on unmovable allocations then anti-frag will fundamentally help
-- get back to me on that when you get
On Saturday 15 September 2007 04:08, Christoph Lameter wrote:
On Fri, 14 Sep 2007, Nick Piggin wrote:
However fsblock can do everything that higher order pagecache can
do in terms of avoiding vmap and giving contiguous memory to block
devices by opportunistically allocating higher orders
On Monday 17 September 2007 04:13, Mel Gorman wrote:
On (15/09/07 14:14), Goswin von Brederlow didst pronounce:
I keep coming back to the fact that movable objects should be moved
out of the way for unmovable ones. Anything else just allows
fragmentation to build up.
This is easily
On Monday 17 September 2007 14:07, David Chinner wrote:
On Fri, Sep 14, 2007 at 06:48:55AM +1000, Nick Piggin wrote:
OK, the vunmap batching code wipes your TLB flushing and IPIs off
the table. Diffstat below, but the TLB portions are here (besides that
_everything_ is probably lower due
On Monday 17 September 2007 19:18, Avi Kivity wrote:
Avi Kivity wrote:
Christoph Hellwig wrote:
On Mon, Sep 17, 2007 at 10:30:43AM +0200, Avi Kivity wrote:
From: Nguyen Anh Quynh [EMAIL PROTECTED]
*nopage() in kvm_main.c should only store the type of mmap() fault if
the pointers are
On Tuesday 18 September 2007 00:09, Anton Altaparmakov wrote:
On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote:
On 15 Sep 2007, at 11:52, Andrew Morton wrote:
On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra
[EMAIL PROTECTED] wrote:
Anyway, looks like all of zone_normal is pinned in
On Friday 14 September 2007 16:02, Soeren Sonnenburg wrote:
> On Thu, 2007-09-13 at 09:51 +1000, Nick Piggin wrote:
> > On Thursday 13 September 2007 19:20, Soeren Sonnenburg wrote:
> > > Dear all,
> > >
> > > I've just seen this in dmesg on a AMD K7 / k
On Thursday 13 September 2007 09:17, Christoph Lameter wrote:
> On Wed, 12 Sep 2007, Nick Piggin wrote:
> > I will still argue that my approach is the better technical solution for
> > large block support than yours, I don't think we made progress on that.
> > And I'm
On Thursday 13 September 2007 09:06, Christoph Lameter wrote:
> On Wed, 12 Sep 2007, Nick Piggin wrote:
> > So lumpy reclaim does not change my formula nor significantly help
> > against a fragmentation attack. AFAIKS.
>
> Lumpy reclaim improves the situation
On Thursday 13 September 2007 12:01, Nick Piggin wrote:
> On Thursday 13 September 2007 23:03, David Chinner wrote:
> > Then just do operations on directories with lots of files in them
> > (tens of thousands). Every directory operation will require at
> > least one vmap in
Should add some comments for the tag barriers (they won't be so important
if we can switch over to the explicit _lock bitops, but for now we should
make it clear).
Jens' original patch said a barrier after the test_and_clear_bit was also
required. I can't see why (and it would prevent the use of
Should add some comments for the tag barriers (they won't be so important
if we can switch over to the explicit _lock bitops, but for now we should
make it clear).
Jens' original patch said a barrier after the test_and_clear_bit was also
required. I can't see why (and it would prevent the use of
On Thursday 13 September 2007 09:06, Christoph Lameter wrote:
On Wed, 12 Sep 2007, Nick Piggin wrote:
So lumpy reclaim does not change my formula nor significantly help
against a fragmentation attack. AFAIKS.
Lumpy reclaim improves the situation significantly because the
overwhelming
On Thursday 13 September 2007 12:01, Nick Piggin wrote:
On Thursday 13 September 2007 23:03, David Chinner wrote:
Then just do operations on directories with lots of files in them
(tens of thousands). Every directory operation will require at
least one vmap in this situation - e.g
On Thursday 13 September 2007 09:17, Christoph Lameter wrote:
On Wed, 12 Sep 2007, Nick Piggin wrote:
I will still argue that my approach is the better technical solution for
large block support than yours, I don't think we made progress on that.
And I'm quite sure we agreed at the VM
On Friday 14 September 2007 16:02, Soeren Sonnenburg wrote:
On Thu, 2007-09-13 at 09:51 +1000, Nick Piggin wrote:
On Thursday 13 September 2007 19:20, Soeren Sonnenburg wrote:
Dear all,
I've just seen this in dmesg on a AMD K7 / kernel 2.6.22.6 machine
(config attached).
Any
On Thursday 13 September 2007 23:03, David Chinner wrote:
> On Thu, Sep 13, 2007 at 03:23:21AM +1000, Nick Piggin wrote:
> > Well, it may not be easy to _fix_, but it's easy to try a few
> > improvements ;)
> >
> > How do I make an image and run a workload that wil
On Friday 14 September 2007 00:46, Frantisek Rysanek wrote:
> Dear everyone,
>
> apologies in advance for a silly question...
>
> I'm using a homebrew stripped-down mini-distro based on Fedora 5,
> with various newer kernels, on a live CD, to test hardware with.
> The live CD is composed by means
On Thursday 13 September 2007 19:20, Soeren Sonnenburg wrote:
> Dear all,
>
> I've just seen this in dmesg on a AMD K7 / kernel 2.6.22.6 machine
> (config attached).
>
> Any ideas / which further information needed ?
Thanks for the report. Is it reproduceable? It seems like the
locks_free_lock
On Thursday 13 September 2007 17:18, David Schwartz wrote:
> > I was working on some unit tests and thought I'd give CFS a whirl to see
> > if it had any impact on my workloads (to see what the fuss was about),
> > and I came up with some pretty disturbing numbers:
> >
On Thursday 13 September 2007 11:49, David Chinner wrote:
> On Wed, Sep 12, 2007 at 01:27:33AM +1000, Nick Piggin wrote:
> > I just gave 4 things which combined might easily reduce xfs vmap overhead
> > by several orders of magnitude, all without changing much code at all.
&g
901 - 1000 of 3926 matches
Mail list logo
