Re: [v1 0/5] parallelized "struct page" zeroing
On Fri, Mar 24, 2017 at 09:51:09AM +0100, Christian Borntraeger wrote: > On 03/24/2017 12:01 AM, Pavel Tatashin wrote: > > When deferred struct page initialization feature is enabled, we get a > > performance gain of initializing vmemmap in parallel after other CPUs are > > started. However, we still zero the memory for vmemmap using one boot CPU. > > This patch-set fixes the memset-zeroing limitation by deferring it as well. > > > > Here is example performance gain on SPARC with 32T: > > base > > https://hastebin.com/ozanelatat.go > > > > fix > > https://hastebin.com/utonawukof.go > > > > As you can see without the fix it takes: 97.89s to boot > > With the fix it takes: 46.91 to boot. > > > > On x86 time saving is going to be even greater (proportionally to memory > > size) > > because there are twice as many "struct page"es for the same amount of > > memory, > > as base pages are twice smaller. > > Fixing the linux-s390 mailing list email. > This might be useful for s390 as well. Unfortunately only for the fake numa case, since as far as I understand it, parallelization happens only on a node granularity. And since we are usually only having one node... But anyway, it won't hurt to set ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT on s390 also. I'll do some testing and then we'll see. Pavel, could you please change your patch 5 so it also converts the s390 call sites of vmemmap_alloc_block() so they use VMEMMAP_ZERO instead of 'true' as argument?
Re: [v1 0/5] parallelized "struct page" zeroing
On Fri, Mar 24, 2017 at 09:51:09AM +0100, Christian Borntraeger wrote: > On 03/24/2017 12:01 AM, Pavel Tatashin wrote: > > When deferred struct page initialization feature is enabled, we get a > > performance gain of initializing vmemmap in parallel after other CPUs are > > started. However, we still zero the memory for vmemmap using one boot CPU. > > This patch-set fixes the memset-zeroing limitation by deferring it as well. > > > > Here is example performance gain on SPARC with 32T: > > base > > https://hastebin.com/ozanelatat.go > > > > fix > > https://hastebin.com/utonawukof.go > > > > As you can see without the fix it takes: 97.89s to boot > > With the fix it takes: 46.91 to boot. > > > > On x86 time saving is going to be even greater (proportionally to memory > > size) > > because there are twice as many "struct page"es for the same amount of > > memory, > > as base pages are twice smaller. > > Fixing the linux-s390 mailing list email. > This might be useful for s390 as well. Unfortunately only for the fake numa case, since as far as I understand it, parallelization happens only on a node granularity. And since we are usually only having one node... But anyway, it won't hurt to set ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT on s390 also. I'll do some testing and then we'll see. Pavel, could you please change your patch 5 so it also converts the s390 call sites of vmemmap_alloc_block() so they use VMEMMAP_ZERO instead of 'true' as argument?
Re: [v1 0/5] parallelized "struct page" zeroing
On 03/24/2017 12:01 AM, Pavel Tatashin wrote: > When deferred struct page initialization feature is enabled, we get a > performance gain of initializing vmemmap in parallel after other CPUs are > started. However, we still zero the memory for vmemmap using one boot CPU. > This patch-set fixes the memset-zeroing limitation by deferring it as well. > > Here is example performance gain on SPARC with 32T: > base > https://hastebin.com/ozanelatat.go > > fix > https://hastebin.com/utonawukof.go > > As you can see without the fix it takes: 97.89s to boot > With the fix it takes: 46.91 to boot. > > On x86 time saving is going to be even greater (proportionally to memory size) > because there are twice as many "struct page"es for the same amount of memory, > as base pages are twice smaller. Fixing the linux-s390 mailing list email. This might be useful for s390 as well. > > > Pavel Tatashin (5): > sparc64: simplify vmemmap_populate > mm: defining memblock_virt_alloc_try_nid_raw > mm: add "zero" argument to vmemmap allocators > mm: zero struct pages during initialization > mm: teach platforms not to zero struct pages memory > > arch/powerpc/mm/init_64.c |4 +- > arch/s390/mm/vmem.c |5 ++- > arch/sparc/mm/init_64.c | 26 +++ > arch/x86/mm/init_64.c |3 +- > include/linux/bootmem.h |3 ++ > include/linux/mm.h| 15 +++-- > mm/memblock.c | 46 -- > mm/page_alloc.c |3 ++ > mm/sparse-vmemmap.c | 48 +--- > 9 files changed, 103 insertions(+), 50 deletions(-) >
Re: [v1 0/5] parallelized "struct page" zeroing
On 03/24/2017 12:01 AM, Pavel Tatashin wrote: > When deferred struct page initialization feature is enabled, we get a > performance gain of initializing vmemmap in parallel after other CPUs are > started. However, we still zero the memory for vmemmap using one boot CPU. > This patch-set fixes the memset-zeroing limitation by deferring it as well. > > Here is example performance gain on SPARC with 32T: > base > https://hastebin.com/ozanelatat.go > > fix > https://hastebin.com/utonawukof.go > > As you can see without the fix it takes: 97.89s to boot > With the fix it takes: 46.91 to boot. > > On x86 time saving is going to be even greater (proportionally to memory size) > because there are twice as many "struct page"es for the same amount of memory, > as base pages are twice smaller. Fixing the linux-s390 mailing list email. This might be useful for s390 as well. > > > Pavel Tatashin (5): > sparc64: simplify vmemmap_populate > mm: defining memblock_virt_alloc_try_nid_raw > mm: add "zero" argument to vmemmap allocators > mm: zero struct pages during initialization > mm: teach platforms not to zero struct pages memory > > arch/powerpc/mm/init_64.c |4 +- > arch/s390/mm/vmem.c |5 ++- > arch/sparc/mm/init_64.c | 26 +++ > arch/x86/mm/init_64.c |3 +- > include/linux/bootmem.h |3 ++ > include/linux/mm.h| 15 +++-- > mm/memblock.c | 46 -- > mm/page_alloc.c |3 ++ > mm/sparse-vmemmap.c | 48 +--- > 9 files changed, 103 insertions(+), 50 deletions(-) >
Re: [v1 0/5] parallelized "struct page" zeroing
On 03/23/2017 07:47 PM, Pasha Tatashin wrote: How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page. Alternatively, just zero out the entire vmemmap area when it is setup in the kernel page tables. Hi Dave, I can do this, either way is fine with me. It would be a little slower compared to the current approach where we benefit from having memset() to work as prefetch. But that would become negligible, once in the future we will increase the granularity of multi-threading, currently it is only one thread per-mnode to multithread vmemamp. Your call. Thank you, Pasha Hi Dave and Matthew, I've been thinking about it some more, and figured that the current approach is better: 1. Most importantly: Part of the vmemmap is initialized early during boot to support Linux to get to the multi-CPU environment. This means that we would need to figure out what part of vmemmap will need to be zeroed before hand in single thread, than zero the rest in multi-thread. This will be very awkward architecturally and error prone. 2. As I already showed, the current approach is significantly faster. So, perhaps it should be the default behavior even for non-deferred "struct page" initialization: unconditionally do not zero vmemmap in memblock allocator, and always zero in __init_single_page(). But, I am afraid it could cause boot time regressions on some platforms where memset() is not optimized, so I would not do it in this patchset. But, hopefully, gradually more platforms will support deferred struct page initialization, and this would become the default behavior. 3. By zeroing "struct page" in __init_single_page(), we set every byte of "struct page" in one place instead of scattering it across different places. So, it could help in the future when we will multi-thread addition of hotplugged memory. Thank you, Pasha
Re: [v1 0/5] parallelized "struct page" zeroing
On 03/23/2017 07:47 PM, Pasha Tatashin wrote: How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page. Alternatively, just zero out the entire vmemmap area when it is setup in the kernel page tables. Hi Dave, I can do this, either way is fine with me. It would be a little slower compared to the current approach where we benefit from having memset() to work as prefetch. But that would become negligible, once in the future we will increase the granularity of multi-threading, currently it is only one thread per-mnode to multithread vmemamp. Your call. Thank you, Pasha Hi Dave and Matthew, I've been thinking about it some more, and figured that the current approach is better: 1. Most importantly: Part of the vmemmap is initialized early during boot to support Linux to get to the multi-CPU environment. This means that we would need to figure out what part of vmemmap will need to be zeroed before hand in single thread, than zero the rest in multi-thread. This will be very awkward architecturally and error prone. 2. As I already showed, the current approach is significantly faster. So, perhaps it should be the default behavior even for non-deferred "struct page" initialization: unconditionally do not zero vmemmap in memblock allocator, and always zero in __init_single_page(). But, I am afraid it could cause boot time regressions on some platforms where memset() is not optimized, so I would not do it in this patchset. But, hopefully, gradually more platforms will support deferred struct page initialization, and this would become the default behavior. 3. By zeroing "struct page" in __init_single_page(), we set every byte of "struct page" in one place instead of scattering it across different places. So, it could help in the future when we will multi-thread addition of hotplugged memory. Thank you, Pasha
Re: [v1 0/5] parallelized "struct page" zeroing
On 03/23/2017 07:35 PM, David Miller wrote: From: Matthew WilcoxDate: Thu, 23 Mar 2017 16:26:38 -0700 On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well. Here is example performance gain on SPARC with 32T: base https://hastebin.com/ozanelatat.go fix https://hastebin.com/utonawukof.go As you can see without the fix it takes: 97.89s to boot With the fix it takes: 46.91 to boot. How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page. Alternatively, just zero out the entire vmemmap area when it is setup in the kernel page tables. Hi Dave, I can do this, either way is fine with me. It would be a little slower compared to the current approach where we benefit from having memset() to work as prefetch. But that would become negligible, once in the future we will increase the granularity of multi-threading, currently it is only one thread per-mnode to multithread vmemamp. Your call. Thank you, Pasha
Re: [v1 0/5] parallelized "struct page" zeroing
On 03/23/2017 07:35 PM, David Miller wrote: From: Matthew Wilcox Date: Thu, 23 Mar 2017 16:26:38 -0700 On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well. Here is example performance gain on SPARC with 32T: base https://hastebin.com/ozanelatat.go fix https://hastebin.com/utonawukof.go As you can see without the fix it takes: 97.89s to boot With the fix it takes: 46.91 to boot. How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page. Alternatively, just zero out the entire vmemmap area when it is setup in the kernel page tables. Hi Dave, I can do this, either way is fine with me. It would be a little slower compared to the current approach where we benefit from having memset() to work as prefetch. But that would become negligible, once in the future we will increase the granularity of multi-threading, currently it is only one thread per-mnode to multithread vmemamp. Your call. Thank you, Pasha
Re: [v1 0/5] parallelized "struct page" zeroing
Hi Matthew, Thank you for your comment. If you look at the data, having memset() actually benefits initializing data. With base it takes: [ 66.148867] node 0 initialised, 128312523 pages in 7200ms With fix: [ 15.260634] node 0 initialised, 128312523 pages in 4190ms So 4.19s vs 7.2s for the same number of "struct page". This is because memset() actually brings "struct page" into cache with efficient block initializing store instruction. I have not tested if there is the same effect on Intel. Pasha On 03/23/2017 07:26 PM, Matthew Wilcox wrote: On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well. Here is example performance gain on SPARC with 32T: base https://hastebin.com/ozanelatat.go fix https://hastebin.com/utonawukof.go As you can see without the fix it takes: 97.89s to boot With the fix it takes: 46.91 to boot. How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org;> em...@kvack.org
Re: [v1 0/5] parallelized "struct page" zeroing
Hi Matthew, Thank you for your comment. If you look at the data, having memset() actually benefits initializing data. With base it takes: [ 66.148867] node 0 initialised, 128312523 pages in 7200ms With fix: [ 15.260634] node 0 initialised, 128312523 pages in 4190ms So 4.19s vs 7.2s for the same number of "struct page". This is because memset() actually brings "struct page" into cache with efficient block initializing store instruction. I have not tested if there is the same effect on Intel. Pasha On 03/23/2017 07:26 PM, Matthew Wilcox wrote: On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well. Here is example performance gain on SPARC with 32T: base https://hastebin.com/ozanelatat.go fix https://hastebin.com/utonawukof.go As you can see without the fix it takes: 97.89s to boot With the fix it takes: 46.91 to boot. How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org;> em...@kvack.org
Re: [v1 0/5] parallelized "struct page" zeroing
From: Matthew WilcoxDate: Thu, 23 Mar 2017 16:26:38 -0700 > On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: >> When deferred struct page initialization feature is enabled, we get a >> performance gain of initializing vmemmap in parallel after other CPUs are >> started. However, we still zero the memory for vmemmap using one boot CPU. >> This patch-set fixes the memset-zeroing limitation by deferring it as well. >> >> Here is example performance gain on SPARC with 32T: >> base >> https://hastebin.com/ozanelatat.go >> >> fix >> https://hastebin.com/utonawukof.go >> >> As you can see without the fix it takes: 97.89s to boot >> With the fix it takes: 46.91 to boot. > > How long does it take if we just don't zero this memory at all? We seem > to be initialising most of struct page in __init_single_page(), so it > seems like a lot of additional complexity to conditionally zero the rest > of struct page. Alternatively, just zero out the entire vmemmap area when it is setup in the kernel page tables.
Re: [v1 0/5] parallelized "struct page" zeroing
From: Matthew Wilcox Date: Thu, 23 Mar 2017 16:26:38 -0700 > On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: >> When deferred struct page initialization feature is enabled, we get a >> performance gain of initializing vmemmap in parallel after other CPUs are >> started. However, we still zero the memory for vmemmap using one boot CPU. >> This patch-set fixes the memset-zeroing limitation by deferring it as well. >> >> Here is example performance gain on SPARC with 32T: >> base >> https://hastebin.com/ozanelatat.go >> >> fix >> https://hastebin.com/utonawukof.go >> >> As you can see without the fix it takes: 97.89s to boot >> With the fix it takes: 46.91 to boot. > > How long does it take if we just don't zero this memory at all? We seem > to be initialising most of struct page in __init_single_page(), so it > seems like a lot of additional complexity to conditionally zero the rest > of struct page. Alternatively, just zero out the entire vmemmap area when it is setup in the kernel page tables.
Re: [v1 0/5] parallelized "struct page" zeroing
On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: > When deferred struct page initialization feature is enabled, we get a > performance gain of initializing vmemmap in parallel after other CPUs are > started. However, we still zero the memory for vmemmap using one boot CPU. > This patch-set fixes the memset-zeroing limitation by deferring it as well. > > Here is example performance gain on SPARC with 32T: > base > https://hastebin.com/ozanelatat.go > > fix > https://hastebin.com/utonawukof.go > > As you can see without the fix it takes: 97.89s to boot > With the fix it takes: 46.91 to boot. How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page.
Re: [v1 0/5] parallelized "struct page" zeroing
On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: > When deferred struct page initialization feature is enabled, we get a > performance gain of initializing vmemmap in parallel after other CPUs are > started. However, we still zero the memory for vmemmap using one boot CPU. > This patch-set fixes the memset-zeroing limitation by deferring it as well. > > Here is example performance gain on SPARC with 32T: > base > https://hastebin.com/ozanelatat.go > > fix > https://hastebin.com/utonawukof.go > > As you can see without the fix it takes: 97.89s to boot > With the fix it takes: 46.91 to boot. How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page.
[v1 0/5] parallelized "struct page" zeroing
When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well. Here is example performance gain on SPARC with 32T: base https://hastebin.com/ozanelatat.go fix https://hastebin.com/utonawukof.go As you can see without the fix it takes: 97.89s to boot With the fix it takes: 46.91 to boot. On x86 time saving is going to be even greater (proportionally to memory size) because there are twice as many "struct page"es for the same amount of memory, as base pages are twice smaller. Pavel Tatashin (5): sparc64: simplify vmemmap_populate mm: defining memblock_virt_alloc_try_nid_raw mm: add "zero" argument to vmemmap allocators mm: zero struct pages during initialization mm: teach platforms not to zero struct pages memory arch/powerpc/mm/init_64.c |4 +- arch/s390/mm/vmem.c |5 ++- arch/sparc/mm/init_64.c | 26 +++ arch/x86/mm/init_64.c |3 +- include/linux/bootmem.h |3 ++ include/linux/mm.h| 15 +++-- mm/memblock.c | 46 -- mm/page_alloc.c |3 ++ mm/sparse-vmemmap.c | 48 +--- 9 files changed, 103 insertions(+), 50 deletions(-)
[v1 0/5] parallelized "struct page" zeroing
When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well. Here is example performance gain on SPARC with 32T: base https://hastebin.com/ozanelatat.go fix https://hastebin.com/utonawukof.go As you can see without the fix it takes: 97.89s to boot With the fix it takes: 46.91 to boot. On x86 time saving is going to be even greater (proportionally to memory size) because there are twice as many "struct page"es for the same amount of memory, as base pages are twice smaller. Pavel Tatashin (5): sparc64: simplify vmemmap_populate mm: defining memblock_virt_alloc_try_nid_raw mm: add "zero" argument to vmemmap allocators mm: zero struct pages during initialization mm: teach platforms not to zero struct pages memory arch/powerpc/mm/init_64.c |4 +- arch/s390/mm/vmem.c |5 ++- arch/sparc/mm/init_64.c | 26 +++ arch/x86/mm/init_64.c |3 +- include/linux/bootmem.h |3 ++ include/linux/mm.h| 15 +++-- mm/memblock.c | 46 -- mm/page_alloc.c |3 ++ mm/sparse-vmemmap.c | 48 +--- 9 files changed, 103 insertions(+), 50 deletions(-)