All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
To: Ralf Hoffmann <ralf.hoffmann@allegro-packets.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v1] change hugepage sorting to avoid overlapping memcpy
Date: Tue, 08 Sep 2015 13:45:42 +0100	[thread overview]
Message-ID: <55EED876.9050307@intel.com> (raw)
In-Reply-To: <1441361677-10271-1-git-send-email-ralf.hoffmann@allegro-packets.com>

Hi Ralf,

Just a few comments/suggestions:

Add 'eal/linux:'  to the commit title, ie:
   "eal/linux: change hugepage sorting to avoid overlapping memcpy"

On 04/09/2015 11:14, Ralf Hoffmann wrote:
> with only one hugepage or already sorted hugepage addresses, the sort
> function called memcpy with same src and dst pointer. Debugging with
> valgrind will issue a warning about overlapping area. This patch changes
> the bubble sort to avoid this behavior. Also, the function cannot fail
> any longer.
>
> Signed-off-by: Ralf Hoffmann <ralf.hoffmann@allegro-packets.com>
> ---
>   lib/librte_eal/linuxapp/eal/eal_memory.c | 27 +++++++++++++--------------
>   1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index ac2745e..6d01f61 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -699,25 +699,25 @@ error:
>    * higher address first on powerpc). We use a slow algorithm, but we won't
>    * have millions of pages, and this is only done at init time.
>    */
> -static int
> +static void
>   sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi)
>   {
>   	unsigned i, j;
> -	int compare_idx;
> +	unsigned compare_idx;
>   	uint64_t compare_addr;
>   	struct hugepage_file tmp;
>   
>   	for (i = 0; i < hpi->num_pages[0]; i++) {
> -		compare_addr = 0;
> -		compare_idx = -1;
> +		compare_addr = hugepg_tbl[i].physaddr;
> +		compare_idx = i;
>   
>   		/*
> -		 * browse all entries starting at 'i', and find the
> +		 * browse all entries starting at 'i+1', and find the
>   		 * entry with the smallest addr
>   		 */
> -		for (j=i; j< hpi->num_pages[0]; j++) {
> +		for (j=i + 1; j < hpi->num_pages[0]; j++) {
Although there are many style/checkpatch issues in current code, we try 
to fix them
in new patches.
In that regard, checkpatch complains about above line with:
ERROR:SPACING: spaces required around that '='

>   
> -			if (compare_addr == 0 ||
> +			if (
>   #ifdef RTE_ARCH_PPC_64
>   				hugepg_tbl[j].physaddr > compare_addr) {
>   #else
> @@ -728,10 +728,9 @@ sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi)
>   			}
>   		}
>   
> -		/* should not happen */
> -		if (compare_idx == -1) {
> -			RTE_LOG(ERR, EAL, "%s(): error in physaddr sorting\n", __func__);
> -			return -1;
> +		if (compare_idx == i) {
> +			/* no smaller page found */
> +			continue;
>   		}
>   
>   		/* swap the 2 entries in the table */
> @@ -741,7 +740,8 @@ sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi)
>   			sizeof(struct hugepage_file));
>   		memcpy(&hugepg_tbl[i], &tmp, sizeof(struct hugepage_file));
>   	}
> -	return 0;
> +
> +	return;
>   }
I reckon checkpatch is not picking this one because the end-of-function 
is not part of the patch,
but it is a warning:
WARNING:RETURN_VOID: void function return statements are not generally 
useful

>   
>   /*
> @@ -1164,8 +1164,7 @@ rte_eal_hugepage_init(void)
>   			goto fail;
>   		}
>   
> -		if (sort_by_physaddr(&tmp_hp[hp_offset], hpi) < 0)
> -			goto fail;
> +		sort_by_physaddr(&tmp_hp[hp_offset], hpi);
>   
>   #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS
>   		/* remap all hugepages into single file segments */
>
>

Thanks,
Sergio

  reply	other threads:[~2015-09-08 12:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04 10:14 [PATCH v1] change hugepage sorting to avoid overlapping memcpy Ralf Hoffmann
2015-09-08 12:45 ` Gonzalez Monroy, Sergio [this message]
2015-09-08 13:29   ` Jay Rolette
2015-09-08 14:24     ` Gonzalez Monroy, Sergio
2016-01-05  9:25       ` [PATCH v2 0/1] " Ralf Hoffmann
2016-01-05  9:25         ` [PATCH v2 1/1] " Ralf Hoffmann
2016-01-05  9:37       ` [PATCH v3 0/1] eal/linux: " Ralf Hoffmann
2016-01-05  9:37         ` [PATCH v3 1/1] " Ralf Hoffmann
2016-01-07  9:33           ` Sergio Gonzalez Monroy
2016-01-07  9:51             ` Sergio Gonzalez Monroy
2016-01-07 10:38               ` Sergio Gonzalez Monroy
2016-01-07 13:58                 ` Ralf Hoffmann
2016-01-07 13:59               ` [PATCH v4 1/1] " Ralf Hoffmann
2016-01-07 14:36                 ` Sergio Gonzalez Monroy
2016-01-07 14:54                   ` [PATCH v5 1/1] eal/linux: " Ralf Hoffmann
2016-03-02 16:13                     ` Thomas Monjalon
2015-09-09  8:41   ` [PATCH v1] " Ralf Hoffmann

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=55EED876.9050307@intel.com \
    --to=sergio.gonzalez.monroy@intel.com \
    --cc=dev@dpdk.org \
    --cc=ralf.hoffmann@allegro-packets.com \
    /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.