a...@linux-foundation.org writes:
> From: Michel Lespinasse <wal...@google.com>
> Subject: mm: use vm_unmapped_area() on powerpc architecture
>
> Update the powerpc slice_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse <wal...@google.com>
> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> Cc: Paul Mackerras <pau...@samba.org>
> Signed-off-by: Andrew Morton <a...@linux-foundation.org>
> ---
>
> arch/powerpc/mm/slice.c | 123 ++++++++++++++++++++++++--------------
> 1 file changed, 78 insertions(+), 45 deletions(-)
>
> diff -puN
> arch/powerpc/mm/slice.c~mm-use-vm_unmapped_area-on-powerpc-architecture
> arch/powerpc/mm/slice.c
> --- a/arch/powerpc/mm/slice.c~mm-use-vm_unmapped_area-on-powerpc-architecture
> +++ a/arch/powerpc/mm/slice.c
> @@ -237,36 +237,69 @@ static void slice_convert(struct mm_stru
> #endif
> }
>
> +/*
> + * Compute which slice addr is part of;
> + * set *boundary_addr to the start or end boundary of that slice
> + * (depending on 'end' parameter);
> + * return boolean indicating if the slice is marked as available in the
> + * 'available' slice_mark.
> + */
> +static bool slice_scan_available(unsigned long addr,
> + struct slice_mask available,
> + int end,
> + unsigned long *boundary_addr)
> +{
> + unsigned long slice;
> + if (addr < SLICE_LOW_TOP) {
> + slice = GET_LOW_SLICE_INDEX(addr);
> + *boundary_addr = (slice + end) << SLICE_LOW_SHIFT;
> + return !!(available.low_slices & (1u << slice));
> + } else {
> + slice = GET_HIGH_SLICE_INDEX(addr);
> + *boundary_addr = (slice + end) ?
> + ((slice + end) << SLICE_HIGH_SHIFT) : SLICE_LOW_TOP;
> + return !!(available.high_slices & (1u << slice));
> + }
> +}
Can you clarify more on when boundary_addr is set to start of the slice
in the comment ? Also may be it would be better if we can say
slice_scan_prev_available and slice_scan_next_available and get rid of
end completely ?
I have tested with both the patches applied and the resulting kernel boots
fine.
-aneesh
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
