Received-SPF: pass (google.com: domain of linux-kernel+bounces-103324-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240311164638.2015063-1-pasha.tatashin@soleen.com>
 <20240311164638.2015063-7-pasha.tatashin@soleen.com> <f5105c5d-59fb-4bca-af70-353e480f2b12@suse.com>
 <CA+CK2bD0ShasU0U5gzp_m99V=NAg1o8wAKH3_+1ghZHmsWhL9w@mail.gmail.com> <6f351959-4711-4a21-8c46-94e536d2eff8@csgroup.eu>
In-Reply-To: <6f351959-4711-4a21-8c46-94e536d2eff8@csgroup.eu>
From: Pasha Tatashin <pasha.tatashin@soleen.com>
Date: Thu, 14 Mar 2024 09:52:29 -0400
Message-ID: <CA+CK2bAXBMsHfeZERKhmMmQGadZFFTUH__AggY4U9vOHJhaGGQ@mail.gmail.com>
Subject: Re: [RFC 06/14] fork: zero vmap stack using clear_page() instead of memset()
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Nikolay Borisov <nik.borisov@suse.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, 
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>, "x86@kernel.org" <x86@kernel.org>, 
	"bp@alien8.de" <bp@alien8.de>, "brauner@kernel.org" <brauner@kernel.org>, 
	"bristot@redhat.com" <bristot@redhat.com>, "bsegall@google.com" <bsegall@google.com>, 
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, 
	"dianders@chromium.org" <dianders@chromium.org>, 
	"dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>, 
	"eric.devolder@oracle.com" <eric.devolder@oracle.com>, "hca@linux.ibm.com" <hca@linux.ibm.com>, 
	"hch@infradead.org" <hch@infradead.org>, "hpa@zytor.com" <hpa@zytor.com>, 
	"jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>, "jgg@ziepe.ca" <jgg@ziepe.ca>, 
	"jpoimboe@kernel.org" <jpoimboe@kernel.org>, "jroedel@suse.de" <jroedel@suse.de>, 
	"juri.lelli@redhat.com" <juri.lelli@redhat.com>, 
	"kent.overstreet@linux.dev" <kent.overstreet@linux.dev>, "kinseyho@google.com" <kinseyho@google.com>, 
	"kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>, "lstoakes@gmail.com" <lstoakes@gmail.com>, 
	"luto@kernel.org" <luto@kernel.org>, "mgorman@suse.de" <mgorman@suse.de>, "mic@digikod.net" <mic@digikod.net>, 
	"michael.christie@oracle.com" <michael.christie@oracle.com>, "mingo@redhat.com" <mingo@redhat.com>, 
	"mjguzik@gmail.com" <mjguzik@gmail.com>, "mst@redhat.com" <mst@redhat.com>, 
	"npiggin@gmail.com" <npiggin@gmail.com>, "peterz@infradead.org" <peterz@infradead.org>, 
	"pmladek@suse.com" <pmladek@suse.com>, 
	"rick.p.edgecombe@intel.com" <rick.p.edgecombe@intel.com>, "rostedt@goodmis.org" <rostedt@goodmis.org>, 
	"surenb@google.com" <surenb@google.com>, "tglx@linutronix.de" <tglx@linutronix.de>, 
	"urezki@gmail.com" <urezki@gmail.com>, 
	"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>, "vschneid@redhat.com" <vschneid@redhat.com>
Content-Type: text/plain; charset="UTF-8"

> But the pages were already physically discontiguous before your change,
> what's the difference ?

Pages were not physically contiguous before my change. They were
allocated with __vmalloc_node_range() which allocates sparse pages and
maps them to a virtually contiguous span of memory within
[VMALLOC_START, VMALLOC_END) range.

> It doesn't matter that the pages are physically discontiguous as far as
> they are virtually contiguous, which should still be the case here for a
> stack.

This patch is a preparation patch for the "dynamic kernel stack"
feature, in the description it says:
This is because with dynamic stacks we might have only partially
populated stacks.

We could compute the populated part of the stack, and determine its
start and end mapped VA range by using vm_area->pages[] and
vm_area->nr_pages, but that would make code a little uglier especially
becuase we would need to take into the account if stack is growing up
or down.. Therefore, using clear_page()  is simpler and should be fast
enough.

Thanks,
Pasha