On Fri, 11 Jan 2008 16:11:15 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> I've just started the patch series, the compile fails for me on a
> powerpc box. global_lru_pages() is defined under CONFIG_PM, but used
> else where in mm/page-writeback.c. None of the global_lru_pages()
> parameters dep
* Rik van Riel <[EMAIL PROTECTED]> [2008-01-08 15:59:39]:
> Changelog:
> - merge memcontroller split LRU code into the main split LRU patch,
> since it is not functionally different (it was split up only to help
> people who had seen the last version of the patch series review it)
Hi, Rik,
I
* Rik van Riel <[EMAIL PROTECTED]> [2008-01-08 15:59:39]:
> On large memory systems, the VM can spend way too much time scanning
> through pages that it cannot (or should not) evict from memory. Not
> only does it use up CPU time, but it also provokes lock contention
> and can leave large systems
On Jan 10, 2008 10:41 AM, Rik van Riel <[EMAIL PROTECTED]> wrote:
>
> On Wed, 9 Jan 2008 23:39:02 -0500
> "Mike Snitzer" <[EMAIL PROTECTED]> wrote:
>
> > How much trouble am I asking for if I were to try to get your patchset
> > to fly on a fairly recent "stable" kernel (e.g. 2.6.22.15)? If
> > wo
On Wed, 9 Jan 2008 23:39:02 -0500
"Mike Snitzer" <[EMAIL PROTECTED]> wrote:
> How much trouble am I asking for if I were to try to get your patchset
> to fly on a fairly recent "stable" kernel (e.g. 2.6.22.15)? If
> workable, is such an effort before it's time relative to your TODO?
Quite a bit
On Jan 8, 2008 3:59 PM, Rik van Riel <[EMAIL PROTECTED]> wrote:
> On large memory systems, the VM can spend way too much time scanning
> through pages that it cannot (or should not) evict from memory. Not
> only does it use up CPU time, but it also provokes lock contention
> and can leave large sys
On Mon, 7 Jan 2008 11:07:54 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Jan 2008, Lee Schermerhorn wrote:
>
> > We see this on both NUMA and non-NUMA. x86_64 and ia64. The basic
> > criteria to reproduce is to be able to run thousands [or low 10s of
> > thousands] of task
On Fri, 4 Jan 2008, Lee Schermerhorn wrote:
> We see this on both NUMA and non-NUMA. x86_64 and ia64. The basic
> criteria to reproduce is to be able to run thousands [or low 10s of
> thousands] of tasks, continually increasing the number until the system
> just goes into reclaim. Instead of swa
On Mon, 7 Jan 2008 19:06:10 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Jan 2008 12:00:00 -0500
> Rik van Riel <[EMAIL PROTECTED]> wrote:
> > If there is no swap space, my VM code will not bother scanning
> > any anon pages. This has the same effect as moving the pages
> > to t
On Thu, 3 Jan 2008 12:00:00 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Thu, 03 Jan 2008 11:52:08 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > Also, I should point out that the full noreclaim series includes a
> > couple of other patches NOT posted here by Rik:
> >
> > 1) tre
Rik van Riel wrote:
On Fri, 04 Jan 2008 17:34:00 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
Lee Schermerhorn <[EMAIL PROTECTED]> writes:
We can easily [he says, glibly] reproduce the hang on the anon_vma lock
Is that a NUMA platform? On non x86? Perhaps you just need queued s
On Fri, 2008-01-04 at 17:34 +0100, Andi Kleen wrote:
> Lee Schermerhorn <[EMAIL PROTECTED]> writes:
>
> > We can easily [he says, glibly] reproduce the hang on the anon_vma lock
>
> Is that a NUMA platform? On non x86? Perhaps you just need queued spinlocks?
We see this on both NUMA and non-NUMA
On Fri, 04 Jan 2008 17:34:00 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Lee Schermerhorn <[EMAIL PROTECTED]> writes:
>
> > We can easily [he says, glibly] reproduce the hang on the anon_vma lock
>
> Is that a NUMA platform? On non x86? Perhaps you just need queued spinlocks?
I really think th
Lee Schermerhorn <[EMAIL PROTECTED]> writes:
> We can easily [he says, glibly] reproduce the hang on the anon_vma lock
Is that a NUMA platform? On non x86? Perhaps you just need queued spinlocks?
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Thu, 2008-01-03 at 17:00 -0500, Rik van Riel wrote:
> On Thu, 03 Jan 2008 12:13:32 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > Yes, but the problem, when it occurs, is very awkward. The system just
> > hangs for hours/days spinning on the reverse mapping locks--in both
> > page_r
On Thu, 03 Jan 2008 12:13:32 -0500
Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> Yes, but the problem, when it occurs, is very awkward. The system just
> hangs for hours/days spinning on the reverse mapping locks--in both
> page_referenced() and try_to_unmap(). No pages get reclaimed and NO OOM
On Thu, 2008-01-03 at 12:00 -0500, Rik van Riel wrote:
> On Thu, 03 Jan 2008 11:52:08 -0500
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > Also, I should point out that the full noreclaim series includes a
> > couple of other patches NOT posted here by Rik:
> >
> > 1) treat swap backed pages
On Thu, 03 Jan 2008 11:52:08 -0500
Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> Also, I should point out that the full noreclaim series includes a
> couple of other patches NOT posted here by Rik:
>
> 1) treat swap backed pages as nonreclaimable when no swap space is
> available. This addresses
On Wed, 2008-01-02 at 17:41 -0500, [EMAIL PROTECTED] wrote:
> On large memory systems, the VM can spend way too much time scanning
> through pages that it cannot (or should not) evict from memory. Not
> only does it use up CPU time, but it also provokes lock contention
> and can leave large systems
19 matches
Mail list logo
