linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: kosaki.motohiro@jp.fujitsu.com, kamezawa.hiroyu@jp.fujitsu.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	riel@redhat.com
Subject: Re: [RFC][PATCH] putback_lru_page()/unevictable page handling rework v3
Date: Tue, 24 Jun 2008 12:19:23 -0700	[thread overview]
Message-ID: <20080624121923.daac91cf.akpm@linux-foundation.org> (raw)
In-Reply-To: <1214334689.6563.63.camel@lts-notebook>

On Tue, 24 Jun 2008 15:11:29 -0400
Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:

> On Tue, 2008-06-24 at 10:55 -0700, Andrew Morton wrote:
> > On Tue, 24 Jun 2008 13:10:53 -0400 Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:
> > 
> > > On Tue, 2008-06-24 at 11:43 +0900, KOSAKI Motohiro wrote:
> > > > Hi
> > > > 
> > > > > I merged kamezawa-san's SHMEM related fix.
> > > > > this patch works well >2H.
> > > > > and, I am going to test on stress workload during this week end.
> > > > > 
> > > > > but I hope recieve review at first.
> > > > > thus I post it now.
> > > > 
> > > > Unfortunately, my machine crashed last night ;-)
> > > > I'll dig it.
> > > 
> > > 
> > > I ran 26-rc5-mm3 with 5 split/unevictable lru patches that you posted on
> > > 19june.  I replaced patch 5 of that series with the subject patch
> > > [rework v3, merged SHMEM fix].  This kernel ran my 'usex' stress load
> > > overnight for 23+ hours on both ia64 and x86_64 platforms with no
> > > problems.  I evidently did not hit the problem you did.
> > > 
> > > I'm rebuilding with a patch to a small problem that I discovered along
> > > with your recent patch to "prevent incorrect oom...".  I'll let you know
> > > how that goes as well.
> > > 
> > > I'll send along two additional patches shortly.
> > > 
> > 
> > My chances of working out which patches I need to apply to -mm are
> > near-zero.  I'm working through my vacation backlog in reverse order
> > and haven't got up to this topic yet.
> > 
> > As you've been paying attention it would be appreciated if you could
> > send me some stuff, please.
> 
> I saw your prior mail to Rik about this, but seem to have deleted it :(.
> 
> The stack that I'm currently running atop 26-rc5-mm3 contains the
> following:
> 
> >From Kosaki Motohiro ~19jun:
> [-mm][PATCH 1/5]  fix munlock page table walk
> [-mm][PATCH 2/5] migration_entry_wait fix.
> [-mm][PATCH 3/5] collect lru meminfo statistics from correct offset
> [-mm][PATCH 4/5]  fix incorrect Mlocked field of /proc/meminfo.
> The following patch replaces 5/5:
> [RFC][PATCH] putback_lru_page()/unevictable page handling rework v3
> The following "rfc" was acked by Rik:
> [RFC][PATCH] prevent incorrect oom under split_lru
> 
> Two that I posted today [24Jun]--fixes to the "rework v3" patch:
> [PATCH] fix to putback_lru_page()/unevictable page handling rework
> [PATCH] fix2 to putback_lru_page()/unevictable page handling
> ___
> The resulting kernel has been running well on my largish ia64 and x86_64
> platforms under a work load that I use to stress reclaim, swapping,
> mlocking, ...  However, Kosaki-san is apparently still experiencing
> panics with a cpuset migration scenario discovered by ___Daisuke
> Nishimura.  We're still investigating the crash, but the patches listed
> above, despite the "rfc" on a couple of them, are an improvement over
> 26-rc5-mm3.
> 
> I believe that Rik has at least one other fix related to "loopback over
> tmpfs" or such.
> 
> Is the list above sufficient to extract the patches from your mail
> backlog, or would you prefer that we resend them?

Please spoon-feed me ;) I can apply them and then I can pick through
the backlog for stuff which might have been missed.

> I'll also send along a patch to update the document to match the
> reworked lru handling methodology that Kamezawa Hiroyuki did.
> 
> Lee

--
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-24 19:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-21 10:00 KOSAKI Motohiro
2008-06-24  2:43 ` KOSAKI Motohiro
2008-06-24 17:10   ` Lee Schermerhorn
2008-06-24 17:55     ` Andrew Morton
2008-06-24 19:11       ` Lee Schermerhorn
2008-06-24 19:19         ` Andrew Morton [this message]
2008-06-24 17:29   ` [PATCH] fix2 to " Lee Schermerhorn
2008-06-24 17:38     ` KOSAKI Motohiro
2008-06-24  9:49 ` [RFC][PATCH] " KOSAKI Motohiro
2008-06-24  9:59   ` KAMEZAWA Hiroyuki
2008-06-24 17:15   ` Lee Schermerhorn
2008-06-24 17:19   ` [PATCH] fix to " Lee Schermerhorn
2008-06-24 17:35     ` KOSAKI Motohiro
2008-06-24 17:48       ` Lee Schermerhorn
2008-06-24 18:19         ` KOSAKI Motohiro

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=20080624121923.daac91cf.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.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