From: Marek Vasut <marex@denx.de>
To: Amos Kong <akong@redhat.com>
Cc: linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au,
davem@davemloft.net
Subject: Re: [PATCH] crypto/xor.c: use 2 pages for xor speed testing
Date: Thu, 5 Jun 2014 23:57:55 +0200 [thread overview]
Message-ID: <201406052357.55383.marex@denx.de> (raw)
In-Reply-To: <1401930693-6549-1-git-send-email-akong@redhat.com>
On Thursday, June 05, 2014 at 03:11:33 AM, Amos Kong wrote:
> In crypto/xor.c: calibrate_xor_blocks(), we allocated total 4 pages to
> do xor speed testing, the BENCH_SIZE is 1 page, and we skipped 2 pages
> when we set b2.
>
> It seems that total 2 pages are enough without skipping 2 pages.
>
> Signed-off-by: Amos Kong <akong@redhat.com>
> ---
> crypto/xor.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/crypto/xor.c b/crypto/xor.c
> index 35d6b3a..609dfb5 100644
> --- a/crypto/xor.c
> +++ b/crypto/xor.c
> @@ -114,12 +114,12 @@ calibrate_xor_blocks(void)
> * test the XOR speed, we don't really want kmemcheck to warn about
> * reading uninitialized bytes here.
> */
> - b1 = (void *) __get_free_pages(GFP_KERNEL | __GFP_NOTRACK, 2);
> + b1 = (void *) __get_free_pages(GFP_KERNEL | __GFP_NOTRACK, 1);
> if (!b1) {
> printk(KERN_WARNING "xor: Yikes! No memory available.\n");
> return -ENOMEM;
> }
> - b2 = b1 + 2*PAGE_SIZE + BENCH_SIZE;
> + b2 = b1 + BENCH_SIZE;
>
> /*
> * If this arch/cpu has a short-circuited selection, don't loop through
> @@ -154,7 +154,7 @@ calibrate_xor_blocks(void)
> #undef xor_speed
>
> out:
> - free_pages((unsigned long)b1, 2);
> + free_pages((unsigned long)b1, 1);
>
> active_template = fastest;
> return 0;
I think this does make sense, but I am not 100% sure, sorry.
...
While looking at this code, can anyone explain to me why we have this stuff in
crypto/xor.c please ?
135 #define xor_speed(templ) do_xor_speed((templ), b1, b2)
136
137 if (fastest) {
138 printk(KERN_INFO "xor: automatically using best "
139 "checksumming function:\n");
140 xor_speed(fastest);
141 goto out;
142 } else {
[...]
149 }
150
151 printk(KERN_INFO "xor: using function: %s (%d.%03d MB/sec)\n",
152 fastest->name, fastest->speed / 1000, fastest->speed % 1000);
153
154 #undef xor_speed
Why do we not call do_xor_speed(fastest, b1, b2); right away , but we #define
xor_speed() instead ? This looks like some remnant or nonsense to me. Shall I
remove that with a patch ?
Best regards,
Marek Vasut
next prev parent reply other threads:[~2014-06-05 21:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 1:11 [PATCH] crypto/xor.c: use 2 pages for xor speed testing Amos Kong
2014-06-05 21:57 ` Marek Vasut [this message]
2014-06-17 7:16 ` Amos Kong
2014-06-25 19:59 ` Marek Vasut
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=201406052357.55383.marex@denx.de \
--to=marex@denx.de \
--cc=akong@redhat.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.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).