From: Michal Hocko <mhocko@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: David Hildenbrand <david@redhat.com>,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
akpm@linux-foundation.org, aarcange@redhat.com,
dan.j.williams@intel.com, konrad.wilk@oracle.com,
lcapitulino@redhat.com, mgorman@techsingularity.net,
mm-commits@vger.kernel.org, mst@redhat.com, osalvador@suse.de,
pagupta@redhat.com, pbonzini@redhat.com, riel@surriel.com,
vbabka@suse.cz, wei.w.wang@intel.com, willy@infradead.org,
yang.zhang.wz@gmail.com, linux-mm@kvack.org
Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree
Date: Thu, 7 Nov 2019 18:46:44 +0100 [thread overview]
Message-ID: <20191107174644.GA8314@dhcp22.suse.cz> (raw)
In-Reply-To: <ec585925-1f72-fbbe-3e24-63aed83b3836@intel.com>
On Thu 07-11-19 09:12:01, Dave Hansen wrote:
[...]
> Both approaches seem totally reasonable to me. I don't like Alex's
> pokes into the core of the allocator, but I also don't like Nitesh's
> extra data structures and the (yet unimplemented) code that it will take
> to make them handle all the things they need to like hotplug.
Well, I would argue that an extra data structure belongs to the user who
is actually using it. Compare that with metadata that is de-facto
maintain athe allocator level which has no real knowledge about the end
user. This is an inherently fragile design as Mel points out in his
earlier email in this thread. I can live with that if that is _really_
necessary but I would rather not to go that way if there is other way.
> There's also a common kernel/hypervisor ABI that's *SHARED* between the
> two approaches. That's really the only thing that would marry us to one
> approach versus the other forever.
>
> Am I missing something? What's the harm in merging the implementation
> that's ready today? If a better one comes along, we'll rip out the ~15
> lines of code in page_alloc.c and merge the better one.
I have asked several times why there is such a push and received no
answer but "this is taking too long" which I honestly do not care much.
Especially when other virt people tend to agree that there is no need to
rush here.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-11-07 17:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191106000547.juQRi83gi%akpm@linux-foundation.org>
2019-11-06 12:16 ` Michal Hocko
2019-11-06 14:09 ` David Hildenbrand
2019-11-06 16:35 ` Alexander Duyck
2019-11-06 16:54 ` Michal Hocko
2019-11-06 17:48 ` Alexander Duyck
2019-11-06 22:11 ` Mel Gorman
2019-11-06 23:38 ` David Hildenbrand
2019-11-07 0:20 ` Alexander Duyck
2019-11-07 10:20 ` Mel Gorman
2019-11-07 16:07 ` Alexander Duyck
2019-11-08 9:43 ` Mel Gorman
2019-11-08 16:17 ` Alexander Duyck
2019-11-08 18:41 ` Mel Gorman
2019-11-08 20:29 ` Alexander Duyck
2019-11-09 14:57 ` Mel Gorman
2019-11-10 18:03 ` Alexander Duyck
2019-11-06 23:33 ` David Hildenbrand
2019-11-07 0:20 ` Dave Hansen
2019-11-07 0:52 ` David Hildenbrand
2019-11-07 17:12 ` Dave Hansen
2019-11-07 17:46 ` Michal Hocko [this message]
2019-11-07 18:08 ` Dave Hansen
2019-11-07 18:12 ` Alexander Duyck
2019-11-08 9:57 ` Michal Hocko
2019-11-08 16:43 ` Alexander Duyck
2019-11-07 18:46 ` Qian Cai
2019-11-07 18:02 ` Alexander Duyck
2019-11-07 19:37 ` Nitesh Narayan Lal
2019-11-07 22:46 ` Alexander Duyck
2019-11-07 22:43 ` David Hildenbrand
2019-11-08 0:42 ` Alexander Duyck
2019-11-08 7:06 ` David Hildenbrand
2019-11-08 17:18 ` Alexander Duyck
2019-11-12 13:04 ` David Hildenbrand
2019-11-12 18:34 ` Alexander Duyck
2019-11-12 21:05 ` David Hildenbrand
2019-11-12 22:17 ` David Hildenbrand
2019-11-12 22:19 ` Alexander Duyck
2019-11-12 23:10 ` David Hildenbrand
2019-11-13 0:31 ` Alexander Duyck
2019-11-13 18:51 ` Nitesh Narayan Lal
2019-11-06 16:49 ` Nitesh Narayan Lal
2019-11-11 18:52 ` Nitesh Narayan Lal
2019-11-11 22:00 ` Alexander Duyck
2019-11-12 15:19 ` Nitesh Narayan Lal
2019-11-12 16:18 ` Alexander Duyck
2019-11-13 18:39 ` Nitesh Narayan Lal
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=20191107174644.GA8314@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=lcapitulino@redhat.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mm-commits@vger.kernel.org \
--cc=mst@redhat.com \
--cc=osalvador@suse.de \
--cc=pagupta@redhat.com \
--cc=pbonzini@redhat.com \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
--cc=wei.w.wang@intel.com \
--cc=willy@infradead.org \
--cc=yang.zhang.wz@gmail.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