Re: [dpdk-dev] [PATCH v2 4/6] mem: use address hint for mapping hugepages

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 03-Jul-18 1:09 PM, Alejandro Lucero wrote:
> Linux kernel uses a really high address as starting address for
> serving mmaps calls. If there exists addressing limitations and
> IOVA mode is VA, this starting address is likely too high for
> those devices. However, it is possible to use a lower address in
> the process virtual address space as with 64 bits there is a lot
> of available space.
> 
> This patch adds an address hint as starting address for 64 bits
> systems.
> 
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> ---

<snip>

> +static void *
> +get_addr_hint(void)
> +{
> +	if (internal_config.base_virtaddr != 0) {
> +		return (void *) (uintptr_t)
> +			    (internal_config.base_virtaddr +
> +			     baseaddr_offset);
> +	}
> +#ifdef RTE_ARCH_64
> +	else {
> +		return (void *) (uintptr_t) (baseaddr +
> +				baseaddr_offset);
> +	}
> +#else
> +	else {
> +		return NULL;
> +	}
> +#endif

Nitpicking, but probably ifdefs should be inside else clause? Two else's 
look weird.

> +}
> +
>   /*
>    * Try to mmap *size bytes in /dev/zero. If it is successful, return the
>    * pointer to the mmap'd area and keep *size unmodified. Else, retry
> @@ -260,16 +297,10 @@
>   static void *
>   get_virtual_area(size_t *size, size_t hugepage_sz)
>   {

<snip>

> -		addr = mmap(addr,
> +		addr_hint = get_addr_hint();
> +
> +		addr = mmap(addr_hint,
>   				(*size) + hugepage_sz, PROT_READ,
>   #ifdef RTE_ARCH_PPC_64
>   				MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,
> @@ -286,8 +319,15 @@
>   				MAP_PRIVATE,
>   #endif
>   				fd, 0);
> -		if (addr == MAP_FAILED)
> +		if (addr == MAP_FAILED) {
> +			/* map failed. Let's try with less memory */
>   			*size -= hugepage_sz;
> +		} else if (addr_hint && addr != addr_hint) {
> +			/* hint was not used. Try with another offset */
> +			munmap(addr, (*size) + hugepage_sz);

Maybe store mapping size in a variable.

Otherwise,

Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

-- 
Thanks,
Anatoly