linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org, lee.schermerhorn@hp.com,
	kosaki.motohiro@jp.fujitsu.com, linux-mm@kvack.org,
	eric.whitney@hp.com
Subject: Re: [PATCH -mm 13/25] Noreclaim LRU Infrastructure
Date: Sun, 8 Jun 2008 22:44:04 -0700	[thread overview]
Message-ID: <20080608224404.086b15ae.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080608225800.17d2e29b@bree.surriel.com>

On Sun, 8 Jun 2008 22:58:00 -0400 Rik van Riel <riel@redhat.com> wrote:

> On Sun, 8 Jun 2008 16:54:34 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > ho hum.  Can you remind us what problems this patchset actually
> > addresses?  Preferably in order of seriousness?
> 
> Here are some other problems that my patch series can easily fix,
> because file cache and anon/swap backed pages live on separate
> LRUs:
> 
> http://feedblog.org/2007/09/29/using-o_direct-on-linux-and-innodb-to-fix-swap-insanity/
> 
> http://blogs.smugmug.com/don/2008/05/01/mysql-and-the-linux-swap-problem/

Sorry, but sending us off to look at random bug reports (from people
who didn't report a bug) is not how we discuss or changelog kernel
patches.

It is for good reasons that we like to see an accurate and detailed
analysis of the problems which are being addressed, and a description
of the means by which they were solved.


> I do not know for sure whether the patch set does fix it yet for
> everyone, or whether it needs some more tuning first, but it is
> fairly easily fixable by tweaking the relative pressure on both
> sets of LRU lists.

I expect it will help, yes.  On 64-bit systems.  It's unclear whether
mlock or SHM_LOCK is part of the issue here - if it is then 32-bit
systems will still be exposed to these things.

I also expect that it will introduce new problems, ones which can take a
very long time to diagnose and fix.  Inevitable, but hopefully acceptable,
if the benefit is there.

> No tricks of skipping over one type of pages while scanning, or
> treating the referenced bits differently when the moon is in some
> particular phase required - one set of lists for each type of
> pages, and variable pressure between the two.

For the unevictable pages we have previously considered just taking
them off the LRU and leaving them off - reattach them at
SHM_UNLOCK-time and at munlock()-time (potentially subject to
reexamination of any other vmas which map each page).

I believe that Andrea had code which leaves the anon pages off the LRU
as well, but I forget the details.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-06-09  5:44 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080606202838.390050172@redhat.com>
2008-06-06 20:28 ` Rik van Riel, Rik van Riel
2008-06-07  1:05   ` Andrew Morton
2008-06-08 20:34     ` Rik van Riel
2008-06-08 20:57       ` Andrew Morton
2008-06-08 21:32         ` Rik van Riel
2008-06-08 21:43           ` Ray Lee
2008-06-08 23:22           ` Andrew Morton
2008-06-08 23:34             ` Rik van Riel
2008-06-08 23:54               ` Andrew Morton
2008-06-09  0:56                 ` Rik van Riel
2008-06-09  6:10                   ` Andrew Morton
2008-06-09 13:44                     ` Rik van Riel
2008-06-09  2:58                 ` Rik van Riel
2008-06-09  5:44                   ` Andrew Morton [this message]
2008-06-10 19:17                 ` Christoph Lameter
2008-06-10 19:37                   ` Rik van Riel
2008-06-10 21:33                     ` Andrew Morton
2008-06-10 21:48                       ` Andi Kleen
2008-06-10 22:05                       ` Dave Hansen
2008-06-11  5:09                       ` Paul Mundt
2008-06-11  6:16                         ` Andrew Morton
2008-06-11  6:29                           ` Paul Mundt
2008-06-11 12:06                           ` Andi Kleen
2008-06-11 14:09                           ` Removing node flags from page->flags was Re: [PATCH -mm 13/25] Noreclaim LRU Infrastructure II Andi Kleen
2008-06-11 19:03                       ` [PATCH -mm 13/25] Noreclaim LRU Infrastructure Andy Whitcroft
2008-06-11 20:52                         ` Andi Kleen
2008-06-11 23:25                         ` Christoph Lameter
2008-06-08 22:03         ` Rik van Riel
2008-06-08 21:07       ` KOSAKI Motohiro
2008-06-10 20:09     ` Rik van Riel
2008-06-06 20:28 ` [PATCH -mm 15/25] Ramfs and Ram Disk pages are non-reclaimable Rik van Riel, Rik van Riel
2008-06-07  1:05   ` Andrew Morton
2008-06-08  4:32     ` Greg KH
2008-06-06 20:28 ` [PATCH -mm 17/25] Mlocked Pages " Rik van Riel, Rik van Riel
2008-06-07  1:07   ` Andrew Morton
2008-06-07  5:38     ` KOSAKI Motohiro
2008-06-10  3:31     ` Nick Piggin
2008-06-10 12:50       ` Rik van Riel
2008-06-10 21:14       ` Rik van Riel
2008-06-10 21:43         ` Lee Schermerhorn
2008-06-10 21:57           ` Andrew Morton
2008-06-11 16:01             ` Lee Schermerhorn
2008-06-10 23:48           ` Rik van Riel
2008-06-11 15:29             ` Lee Schermerhorn
2008-06-11  1:00     ` Rik van Riel
2008-06-06 20:28 ` [PATCH -mm 19/25] Handle mlocked pages during map, remap, unmap Rik van Riel, Rik van Riel
2008-06-06 20:28 ` [PATCH -mm 21/25] Cull non-reclaimable pages in fault path Rik van Riel, Rik van Riel, Lee Schermerhorn
2008-06-06 20:29 ` [PATCH -mm 23/25] Noreclaim LRU scan sysctl Rik van Riel, Rik van Riel, Lee Schermerhorn
2008-06-06 20:29 ` [PATCH -mm 25/25] Noreclaim LRU and Mlocked Pages Documentation Rik van Riel, Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080608224404.086b15ae.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=eric.whitney@hp.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox