linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Lee.Schermerhorn@hp.com, riel@redhat.com,
	kamezawa.hiroyu@jp.fujitsu.com
Subject: Re: [-mm][PATCH 10/10] putback_lru_page()/unevictable page handling rework v4
Date: Wed, 25 Jun 2008 15:13:16 -0700	[thread overview]
Message-ID: <20080625151316.58ed195e.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080625191237.D86D.KOSAKI.MOTOHIRO@jp.fujitsu.com>

On Wed, 25 Jun 2008 19:14:54 +0900
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:

> putback_lru_page()/unevictable page handling rework.

The other nine patches slotted into the patch series quite nicely. 
This means that those nine patches can later be folded into the patches
which they fixed and everything is nice and logical.

But this patch is not like that - it changes code which was added by
lots of different patches.  This means that if I merge it, this patch
besomes a sort of impermeable barrier which other patches cannot be
reordered across.

And that's kind-of OK.  It's messy, but we could live with it.  However
as I expect there will be more fixes to these patches before all this
work goes into mainline, this particular patch will become more of a
problem as it will make the whole body of work more messy and harder to
review and understand.

So.  Can this patch be simplified in any way?  Or split up into
finer-grained patches or something like that?

Thanks.

--
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-25 22:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25  9:59 [-mm][PATCH 0/10] memory related bugfix set for 2.6.26-rc5-mm3 v2 KOSAKI Motohiro
2008-06-25 10:01 ` [-mm][PATCH 1/10] fix UNEVICTABLE_LRU and !PROC_PAGE_MONITOR build KOSAKI Motohiro
2008-07-03  5:36   ` Andrew Morton
2008-07-03  6:02     ` KOSAKI Motohiro
2008-07-03 13:16       ` Rik van Riel
2008-06-25 10:02 ` [-mm][PATCH 2/10] fix printk in show_free_areas() KOSAKI Motohiro
2008-06-25 10:03 ` [-mm][PATCH 3/10] fix munlock page table walk - now requires 'mm' KOSAKI Motohiro
2008-06-25 10:04 ` [-mm][PATCH 4/10] fix migration_entry_wait() for speculative page cache KOSAKI Motohiro
2008-06-25 10:05 ` [-mm][PATCH 5/10] collect lru meminfo statistics from correct offset KOSAKI Motohiro
2008-06-25 10:06 ` [-mm][PATCH 6/10] fix incorrect Mlocked field of /proc/meminfo KOSAKI Motohiro
2008-06-25 10:07 ` [-mm][PATCH 7/10] prevent incorrect oom under split_lru KOSAKI Motohiro
2008-06-25 10:09 ` [-mm][PATCH 8/10] fix shmem page migration incorrectness on memcgroup KOSAKI Motohiro
2008-06-27  5:08   ` MinChan Kim
2008-06-27  5:41     ` KOSAKI Motohiro
2008-06-27  7:57       ` MinChan Kim
2008-06-27  8:52         ` KAMEZAWA Hiroyuki
2008-06-27  9:29           ` Daisuke Nishimura
2008-06-27 10:13           ` MinChan Kim
2008-06-27 12:24           ` kamezawa.hiroyu
2008-06-25 10:10 ` [-mm][PATCH 9/10] memcg: fix mem_cgroup_end_migration() race KOSAKI Motohiro
2008-06-25 10:53   ` Daisuke Nishimura
2008-06-25 10:11 ` [-mm][PATCH 10/10] putback_lru_page()/unevictable page handling rework v4 KOSAKI Motohiro
2008-06-25 10:14   ` KOSAKI Motohiro
2008-06-25 22:13     ` Andrew Morton [this message]
2008-06-26  1:31       ` KOSAKI Motohiro
2008-06-25 16:29   ` Lee Schermerhorn
2008-06-26  8:08     ` KOSAKI Motohiro
2008-06-25 15:09 ` [-mm][PATCH 0/10] memory related bugfix set for 2.6.26-rc5-mm3 v2 Lee Schermerhorn

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=20080625151316.58ed195e.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