From: Nicholas Piggin <nicholas.piggin@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
paulus@samba.org, mpe@ellerman.id.au,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2 2/4] powerpc/mm/slice: Reduce the stack usage in slice_get_unmapped_area
Date: Tue, 27 Feb 2018 08:24:29 +1000 [thread overview]
Message-ID: <CANashXPZ=KZdixoqCoO7hTy4z7kJLqAst6C-77fg7OdAdfe8EA@mail.gmail.com> (raw)
In-Reply-To: <20180226140826.11641-3-aneesh.kumar@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5338 bytes --]
I had a series which goes significantly further with stack reduction. What
do you think about just going with that?
I wonder if we should switch to dynamically allocating the slice stuff on
ppc64
On 27 Feb. 2018 00:28, "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
wrote:
> This patch kill potential_mask and compat_mask variable and instead use
> tmp_mask
> so that we can reduce the stack usage. This is required so that we can
> increase
> the high_slices bitmap to a larger value.
>
> The patch does result in extra computation in final stage, where it ends up
> recomputing the compat mask again.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/slice.c | 34 +++++++++++++++++-----------------
> 1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
> index 259bbda9a222..832c681c341a 100644
> --- a/arch/powerpc/mm/slice.c
> +++ b/arch/powerpc/mm/slice.c
> @@ -413,8 +413,7 @@ unsigned long slice_get_unmapped_area(unsigned long
> addr, unsigned long len,
> {
> struct slice_mask mask;
> struct slice_mask good_mask;
> - struct slice_mask potential_mask;
> - struct slice_mask compat_mask;
> + struct slice_mask tmp_mask;
> int fixed = (flags & MAP_FIXED);
> int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT);
> unsigned long page_size = 1UL << pshift;
> @@ -449,11 +448,8 @@ unsigned long slice_get_unmapped_area(unsigned long
> addr, unsigned long len,
> bitmap_zero(mask.high_slices, SLICE_NUM_HIGH);
>
> /* silence stupid warning */;
> - potential_mask.low_slices = 0;
> - bitmap_zero(potential_mask.high_slices, SLICE_NUM_HIGH);
> -
> - compat_mask.low_slices = 0;
> - bitmap_zero(compat_mask.high_slices, SLICE_NUM_HIGH);
> + tmp_mask.low_slices = 0;
> + bitmap_zero(tmp_mask.high_slices, SLICE_NUM_HIGH);
>
> /* Sanity checks */
> BUG_ON(mm->task_size == 0);
> @@ -502,9 +498,11 @@ unsigned long slice_get_unmapped_area(unsigned long
> addr, unsigned long len,
> #ifdef CONFIG_PPC_64K_PAGES
> /* If we support combo pages, we can allow 64k pages in 4k slices
> */
> if (psize == MMU_PAGE_64K) {
> - slice_mask_for_size(mm, MMU_PAGE_4K, &compat_mask,
> high_limit);
> + slice_mask_for_size(mm, MMU_PAGE_4K, &tmp_mask,
> high_limit);
> if (fixed)
> - slice_or_mask(&good_mask, &compat_mask);
> + slice_or_mask(&good_mask, &tmp_mask);
> +
> + slice_print_mask("Mask for compat page size", tmp_mask);
> }
> #endif
> /* First check hint if it's valid or if we have MAP_FIXED */
> @@ -541,11 +539,11 @@ unsigned long slice_get_unmapped_area(unsigned long
> addr, unsigned long len,
> * We don't fit in the good mask, check what other slices are
> * empty and thus can be converted
> */
> - slice_mask_for_free(mm, &potential_mask, high_limit);
> - slice_or_mask(&potential_mask, &good_mask);
> - slice_print_mask(" potential", potential_mask);
> + slice_mask_for_free(mm, &tmp_mask, high_limit);
> + slice_or_mask(&tmp_mask, &good_mask);
> + slice_print_mask("Free area/potential ", tmp_mask);
>
> - if ((addr != 0 || fixed) && slice_check_fit(mm, mask,
> potential_mask)) {
> + if ((addr != 0 || fixed) && slice_check_fit(mm, mask, tmp_mask)) {
> slice_dbg(" fits potential !\n");
> goto convert;
> }
> @@ -571,7 +569,7 @@ unsigned long slice_get_unmapped_area(unsigned long
> addr, unsigned long len,
> /* Now let's see if we can find something in the existing slices
> * for that size plus free slices
> */
> - addr = slice_find_area(mm, len, potential_mask,
> + addr = slice_find_area(mm, len, tmp_mask,
> psize, topdown, high_limit);
>
> #ifdef CONFIG_PPC_64K_PAGES
> @@ -585,9 +583,10 @@ unsigned long slice_get_unmapped_area(unsigned long
> addr, unsigned long len,
> * mask variable is free here. Use that for compat
> * size mask.
> */
> + slice_mask_for_size(mm, MMU_PAGE_4K, &mask, high_limit);
> /* retry the search with 4k-page slices included */
> - slice_or_mask(&potential_mask, &compat_mask);
> - addr = slice_find_area(mm, len, potential_mask,
> + slice_or_mask(&tmp_mask, &mask);
> + addr = slice_find_area(mm, len, tmp_mask,
> psize, topdown, high_limit);
> }
> #endif
> @@ -600,8 +599,9 @@ unsigned long slice_get_unmapped_area(unsigned long
> addr, unsigned long len,
> slice_print_mask(" mask", mask);
>
> convert:
> + slice_mask_for_size(mm, MMU_PAGE_4K, &tmp_mask, high_limit);
> slice_andnot_mask(&mask, &good_mask);
> - slice_andnot_mask(&mask, &compat_mask);
> + slice_andnot_mask(&mask, &tmp_mask);
> if (mask.low_slices || !bitmap_empty(mask.high_slices,
> SLICE_NUM_HIGH)) {
> slice_convert(mm, mask, psize);
> if (psize > MMU_PAGE_BASE)
> --
> 2.14.3
>
>
[-- Attachment #2: Type: text/html, Size: 6684 bytes --]
next prev parent reply other threads:[~2018-02-26 22:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-26 14:08 [PATCH V2 0/4] Add support for 4PB virtual address space on hash Aneesh Kumar K.V
2018-02-26 14:08 ` [PATCH V2 1/4] powerpc/mm/slice: Update documentation in the file Aneesh Kumar K.V
2018-02-26 14:08 ` [PATCH V2 2/4] powerpc/mm/slice: Reduce the stack usage in slice_get_unmapped_area Aneesh Kumar K.V
2018-02-26 22:24 ` Nicholas Piggin [this message]
2018-02-27 4:01 ` Aneesh Kumar K.V
2018-02-26 14:08 ` [PATCH V2 3/4] powerpc/mm: Add support for handling > 512TB address in SLB miss Aneesh Kumar K.V
2018-02-26 14:08 ` [PATCH V2 4/4] powerpc/mm/hash64: Increase the VA range Aneesh Kumar K.V
2018-02-26 18:11 ` Murilo Opsfelder Araujo
2018-02-27 4:02 ` Aneesh Kumar K.V
2018-02-28 23:06 ` kbuild test robot
2018-02-26 14:15 ` [PATCH V2 0/4] Add support for 4PB virtual address space on hash Aneesh Kumar K.V
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='CANashXPZ=KZdixoqCoO7hTy4z7kJLqAst6C-77fg7OdAdfe8EA@mail.gmail.com' \
--to=nicholas.piggin@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.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 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).