From: David Laight <David.Laight@ACULAB.COM>
To: "'Michal Hocko'" <mhocko@kernel.org>
Cc: "'Pavel Tatashin'" <pasha.tatashin@oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"x86@kernel.org" <x86@kernel.org>,
"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"willy@infradead.org" <willy@infradead.org>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"sam@ravnborg.org" <sam@ravnborg.org>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
"steven.sistare@oracle.com" <steven.sistare@oracle.com>,
"daniel.m.jordan@oracle.com" <daniel.m.jordan@oracle.com>,
"bob.picco@oracle.com" <bob.picco@oracle.com>
Subject: RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap
Date: Fri, 6 Oct 2017 12:11:42 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD008BB4D@AcuExch.aculab.com> (raw)
In-Reply-To: <20171006114729.fexwklupkhyxdpt3@dhcp22.suse.cz>
From: Michal Hocko
> Sent: 06 October 2017 12:47
> On Fri 06-10-17 11:10:14, David Laight wrote:
> > From: Pavel Tatashin
> > > Sent: 05 October 2017 22:11
> > > vmemmap_alloc_block() will no longer zero the block, so zero memory
> > > at its call sites for everything except struct pages. Struct page memory
> > > is zero'd by struct page initialization.
> >
> > It seems dangerous to change an allocator to stop zeroing memory.
> > It is probably saver to add a new function that doesn't zero
> > the memory and use that is the places where you don't want it
> > to be zeroed.
>
> Not sure what you mean. memblock_virt_alloc_try_nid_raw is a new
> function which doesn't zero out...
You should probably leave vmemap_alloc_block() zeroing the memory
so that existing alls don't have to be changed - apart from the
ones you are explicitly optimising.
David
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: linux-arm-kernel@lists.infradead.org
Subject: RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap
Date: Fri, 06 Oct 2017 12:11:42 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD008BB4D@AcuExch.aculab.com> (raw)
In-Reply-To: <20171006114729.fexwklupkhyxdpt3@dhcp22.suse.cz>
From: Michal Hocko
> Sent: 06 October 2017 12:47
> On Fri 06-10-17 11:10:14, David Laight wrote:
> > From: Pavel Tatashin
> > > Sent: 05 October 2017 22:11
> > > vmemmap_alloc_block() will no longer zero the block, so zero memory
> > > at its call sites for everything except struct pages. Struct page memory
> > > is zero'd by struct page initialization.
> >
> > It seems dangerous to change an allocator to stop zeroing memory.
> > It is probably saver to add a new function that doesn't zero
> > the memory and use that is the places where you don't want it
> > to be zeroed.
>
> Not sure what you mean. memblock_virt_alloc_try_nid_raw is a new
> function which doesn't zero out...
You should probably leave vmemap_alloc_block() zeroing the memory
so that existing alls don't have to be changed - apart from the
ones you are explicitly optimising.
David
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Michal Hocko' <mhocko@kernel.org>
Cc: 'Pavel Tatashin' <pasha.tatashin@oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"x86@kernel.org" <x86@kernel.org>,
"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"willy@infradead.org" <willy@infradead.org>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"sam@ravnborg.org" <sam@ravnborg.org>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
"steven.sistare@oracle.com" <steven.sistare@oracle.com>,
"daniel.m.jordan@oracle.com" <daniel.m.jordan@oracle.com>,
"bob.picco@oracle.com" <bob.picco@oracle.com>
Subject: RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap
Date: Fri, 6 Oct 2017 12:11:42 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD008BB4D@AcuExch.aculab.com> (raw)
In-Reply-To: <20171006114729.fexwklupkhyxdpt3@dhcp22.suse.cz>
From: Michal Hocko
> Sent: 06 October 2017 12:47
> On Fri 06-10-17 11:10:14, David Laight wrote:
> > From: Pavel Tatashin
> > > Sent: 05 October 2017 22:11
> > > vmemmap_alloc_block() will no longer zero the block, so zero memory
> > > at its call sites for everything except struct pages. Struct page memory
> > > is zero'd by struct page initialization.
> >
> > It seems dangerous to change an allocator to stop zeroing memory.
> > It is probably saver to add a new function that doesn't zero
> > the memory and use that is the places where you don't want it
> > to be zeroed.
>
> Not sure what you mean. memblock_virt_alloc_try_nid_raw is a new
> function which doesn't zero out...
You should probably leave vmemap_alloc_block() zeroing the memory
so that existing alls don't have to be changed - apart from the
ones you are explicitly optimising.
David
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Michal Hocko' <mhocko@kernel.org>
Cc: 'Pavel Tatashin' <pasha.tatashin@oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"x86@kernel.org" <x86@kernel.org>,
"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"willy@infradead.org" <willy@infradead.org>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"sam@ravnborg.org" <sam@ravnborg.org>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
"steven.sistare@oracle.com" <steven.sistare@oracle.com>,
"daniel.m.jordan@oracle.com" <daniel.m.jordan@oracle.com>,
"bob.picco@oracle.com" <bob.picco@oracle.com>
Subject: RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap
Date: Fri, 6 Oct 2017 12:11:42 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD008BB4D@AcuExch.aculab.com> (raw)
In-Reply-To: <20171006114729.fexwklupkhyxdpt3@dhcp22.suse.cz>
From: Michal Hocko
> Sent: 06 October 2017 12:47
> On Fri 06-10-17 11:10:14, David Laight wrote:
> > From: Pavel Tatashin
> > > Sent: 05 October 2017 22:11
> > > vmemmap_alloc_block() will no longer zero the block, so zero memory
> > > at its call sites for everything except struct pages. Struct page me=
mory
> > > is zero'd by struct page initialization.
> >
> > It seems dangerous to change an allocator to stop zeroing memory.
> > It is probably saver to add a new function that doesn't zero
> > the memory and use that is the places where you don't want it
> > to be zeroed.
>=20
> Not sure what you mean. memblock_virt_alloc_try_nid_raw is a new
> function which doesn't zero out...
You should probably leave vmemap_alloc_block() zeroing the memory
so that existing alls don't have to be changed - apart from the
ones you are explicitly optimising.
David
WARNING: multiple messages have this Message-ID (diff)
From: David.Laight@ACULAB.COM (David Laight)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap
Date: Fri, 6 Oct 2017 12:11:42 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD008BB4D@AcuExch.aculab.com> (raw)
In-Reply-To: <20171006114729.fexwklupkhyxdpt3@dhcp22.suse.cz>
From: Michal Hocko
> Sent: 06 October 2017 12:47
> On Fri 06-10-17 11:10:14, David Laight wrote:
> > From: Pavel Tatashin
> > > Sent: 05 October 2017 22:11
> > > vmemmap_alloc_block() will no longer zero the block, so zero memory
> > > at its call sites for everything except struct pages. Struct page memory
> > > is zero'd by struct page initialization.
> >
> > It seems dangerous to change an allocator to stop zeroing memory.
> > It is probably saver to add a new function that doesn't zero
> > the memory and use that is the places where you don't want it
> > to be zeroed.
>
> Not sure what you mean. memblock_virt_alloc_try_nid_raw is a new
> function which doesn't zero out...
You should probably leave vmemap_alloc_block() zeroing the memory
so that existing alls don't have to be changed - apart from the
ones you are explicitly optimising.
David
next prev parent reply other threads:[~2017-10-06 12:11 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 21:11 [PATCH v10 00/10] complete deferred page initialization Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 01/10] x86/mm: setting fields in deferred pages Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 02/10] sparc64/mm: " Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 03/10] sparc64: simplify vmemmap_populate Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 04/10] mm: defining memblock_virt_alloc_try_nid_raw Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 05/10] mm: zero reserved and unavailable struct pages Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-06 12:30 ` Michal Hocko
2017-10-06 12:30 ` Michal Hocko
2017-10-06 12:30 ` Michal Hocko
2017-10-06 12:30 ` Michal Hocko
2017-10-06 15:25 ` Pasha Tatashin
2017-10-06 15:25 ` Pasha Tatashin
2017-10-06 15:25 ` Pasha Tatashin
2017-10-06 15:25 ` Pasha Tatashin
2017-10-10 13:39 ` Michal Hocko
2017-10-10 13:39 ` Michal Hocko
2017-10-10 13:39 ` Michal Hocko
2017-10-10 13:39 ` Michal Hocko
2017-10-05 21:11 ` [PATCH v10 06/10] mm/kasan: kasan specific map populate function Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 07/10] x86/kasan: use kasan_map_populate() Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 08/10] arm64/kasan: " Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-06 11:10 ` David Laight
2017-10-06 11:10 ` David Laight
2017-10-06 11:10 ` David Laight
2017-10-06 11:10 ` David Laight
2017-10-06 11:10 ` David Laight
2017-10-06 11:47 ` Michal Hocko
2017-10-06 11:47 ` Michal Hocko
2017-10-06 11:47 ` Michal Hocko
2017-10-06 11:47 ` Michal Hocko
2017-10-06 11:47 ` Michal Hocko
2017-10-06 12:11 ` David Laight [this message]
2017-10-06 12:11 ` David Laight
2017-10-06 12:11 ` David Laight
2017-10-06 12:11 ` David Laight
2017-10-06 12:11 ` David Laight
2017-10-06 12:25 ` Michal Hocko
2017-10-06 12:25 ` Michal Hocko
2017-10-06 12:25 ` Michal Hocko
2017-10-06 12:25 ` Michal Hocko
2017-10-06 12:25 ` Michal Hocko
2017-10-05 21:11 ` [PATCH v10 10/10] sparc64: optimized struct page zeroing Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
2017-10-05 21:11 ` Pavel Tatashin
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=063D6719AE5E284EB5DD2968C1650D6DD008BB4D@AcuExch.aculab.com \
--to=david.laight@aculab.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bob.picco@oracle.com \
--cc=borntraeger@de.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=daniel.m.jordan@oracle.com \
--cc=davem@davemloft.net \
--cc=heiko.carstens@de.ibm.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=pasha.tatashin@oracle.com \
--cc=sam@ravnborg.org \
--cc=sparclinux@vger.kernel.org \
--cc=steven.sistare@oracle.com \
--cc=will.deacon@arm.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.