linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Tatashin <pasha.tatashin@oracle.com>
To: mhocko@kernel.org
Cc: Steven Sistare <steven.sistare@oracle.com>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	tglx@linutronix.de,
	Linux Memory Management List <linux-mm@kvack.org>,
	mgorman@techsingularity.net, mingo@kernel.org,
	peterz@infradead.org, Steven Rostedt <rostedt@goodmis.org>,
	Fengguang Wu <fengguang.wu@intel.com>,
	Dennis Zhou <dennisszhou@gmail.com>
Subject: Re: [PATCH v2] mm: allow deferred page init for vmemmap only
Date: Tue, 15 May 2018 08:17:27 -0400	[thread overview]
Message-ID: <CAGM2reaQusBA-nmQ5xqH4u-EVxgJCnaHAZs=1AXFOpNWTh7VbQ@mail.gmail.com> (raw)
In-Reply-To: <20180515091036.GC12670@dhcp22.suse.cz>

Hi Michal,

Thank you for your reply, my comments below:

> You are now disabling a potentially useful feature to SPARSEMEM users
> without having any evidence that they do suffer from the issue which is
> kinda sad. Especially when the only known offender is a UP pcp allocator
> implementation.

True, but what is the use case for having SPARSEMEM without virtual mapping
and deferred struct page init together. Is it a common case to have
multiple gigabyte of memory and currently NUMA config to benefit from
deferred page init and yet not having a memory for virtual mapping of
struct pages? Or am I missing some common case here?

> I will not insist of course but it seems like your fix doesn't really
> prevent virt_to_page or other direct page access either.

I am not sure what do you mean, I do not prevent virt_to_page, but that is
OK for SPARSEMEM_VMEMMAP case, because we do not need to access "struct
page" for this operation, as translation is in page table. Yes, we do not
prohibit other struct page accesses before mm_init(), but we now have a
feature that checks for uninitialized struct page access, and if those will
happen, we will learn about them.

Thank you,
Pavel

  reply	other threads:[~2018-05-15 12:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 11:53 [PATCH v2] mm: allow deferred page init for vmemmap only Pavel Tatashin
2018-05-10 12:30 ` Michal Hocko
2018-05-11 14:17   ` Pavel Tatashin
2018-05-15  9:10     ` Michal Hocko
2018-05-15 12:17       ` Pavel Tatashin [this message]
2018-05-15 12:55         ` Michal Hocko
2018-05-15 15:59           ` Pavel Tatashin
2018-05-15 20:38             ` Michal Hocko

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='CAGM2reaQusBA-nmQ5xqH4u-EVxgJCnaHAZs=1AXFOpNWTh7VbQ@mail.gmail.com' \
    --to=pasha.tatashin@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.m.jordan@oracle.com \
    --cc=dennisszhou@gmail.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=steven.sistare@oracle.com \
    --cc=tglx@linutronix.de \
    /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).