linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	William Kucharski <william.kucharski@oracle.com>,
	linux- stable <stable@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>, Arnd Bergmann <arnd@arndb.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roman Gushchin <guro@fb.com>, Michal Hocko <mhocko@kernel.org>,
	lkft-triage@lists.linaro.org, Chris Down <chris@chrisdown.name>,
	Michel Lespinasse <walken@google.com>,
	Fan Yang <Fan_Yang@sjtu.edu.cn>,
	Brian Geffon <bgeffon@google.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	pugaowei@gmail.com, Jerome Glisse <jglisse@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Hugh Dickins <hughd@google.com>,
	Al Viro <viro@zeniv.linux.org.uk>, Tejun Heo <tj@kernel.org>,
	Sasha Levin <sashal@kernel.org>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: WARNING: at mm/mremap.c:211 move_page_tables in i386
Date: Sun, 12 Jul 2020 18:30:52 +0100	[thread overview]
Message-ID: <20200712173052.GU12769@casper.infradead.org> (raw)
In-Reply-To: <CAHk-=wj_Bqu5n3OJCnKiO_gs97fYEpdx6eSacEw2kv9YnnSv_w@mail.gmail.com>

On Sat, Jul 11, 2020 at 11:12:58AM -0700, Linus Torvalds wrote:
> Yeah, that's just the commit that enables the code, not the commit
> that introduces the fundamental problem.
> 
> That said, this is a prime example of why I absolutely detest patch
> series that do this kind of thing, and are several patches that create
> new functionality, followed by one patch to enable it.
> 
> If you can't get things working incrementally, maybe you shouldn't do
> them at all. Doing a big series of "hidden work" and then enabling it
> later is wrong.

I'm struggling with exactly this for my current THP-in-pagecache patches.
There are about fifty patches, each fixing something that won't work if
the page is a THP.  And then there's the one patch which actually starts
creating THPs, and that's the one patch any bisect will point to.

But I don't see any other way to do it.  It's not like I can put THPs
in the page cache before fixing the things that won't work.

This probably wasn't the kind of thing you had in mind when you wrote
the above, but if you had some advice for my situation, I'd welcome it.


  parent reply	other threads:[~2020-07-12 17:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09  5:28 WARNING: at mm/mremap.c:211 move_page_tables in i386 Naresh Kamboju
2020-07-09  8:25 ` Arnd Bergmann
2020-07-10  4:17   ` Naresh Kamboju
2020-07-09 19:12 ` Linus Torvalds
2020-07-10  4:28   ` Naresh Kamboju
2020-07-10  5:22     ` Linus Torvalds
2020-07-10 17:48       ` Naresh Kamboju
2020-07-10 20:05         ` Linus Torvalds
2020-07-11 17:27           ` Naresh Kamboju
2020-07-11 18:12             ` Linus Torvalds
2020-07-11 18:21               ` Linus Torvalds
2020-07-11 23:33               ` Joel Fernandes
2020-07-12 17:30               ` Matthew Wilcox [this message]
2020-07-12 20:38                 ` Linus Torvalds
2020-07-12 21:50       ` Joel Fernandes
2020-07-12 22:58         ` Linus Torvalds
2020-07-13  2:53           ` Joel Fernandes
2020-07-13  3:51             ` Linus Torvalds
2020-07-13 12:12               ` Joel Fernandes
2020-07-14  7:33           ` Kirill A. Shutemov
2020-07-14 11:27             ` Naresh Kamboju
2020-07-14 16:08             ` Joel Fernandes
2020-07-14 16:10               ` Linus Torvalds
2020-07-14 18:12                 ` Joel Fernandes
2020-07-14 18:49                   ` Linus Torvalds

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=20200712173052.GU12769@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=Fan_Yang@sjtu.edu.cn \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=arnd@arndb.de \
    --cc=bgeffon@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=chris@chrisdown.name \
    --cc=gregkh@linuxfoundation.org \
    --cc=guro@fb.com \
    --cc=hughd@google.com \
    --cc=jglisse@redhat.com \
    --cc=joel@joelfernandes.org \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=oleg@redhat.com \
    --cc=pugaowei@gmail.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=walken@google.com \
    --cc=will@kernel.org \
    --cc=william.kucharski@oracle.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;
as well as URLs for NNTP newsgroup(s).