From: scottwood@freescale•com (Scott Wood)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] kexec: Add --lite option
Date: Mon, 7 Dec 2015 19:03:20 -0600 [thread overview]
Message-ID: <1449536600.15946.102.camel@freescale.com> (raw)
In-Reply-To: <20151207140755.GG16406@dhcppc13.redhat.com>
On Mon, 2015-12-07 at 19:37 +0530, Pratyush Anand wrote:
> Hi James,
>
> Thanks for the reply.
>
> On 07/12/2015:01:16:06 PM, James Morse wrote:
> > Hi Pratyush,
> >
> > On 07/12/15 11:48, Pratyush Anand wrote:
> > > > 1) When we execute kexec() system call in first kernel, at that time
> > > > it
> > > > calculates sha256 on all the binaries [1]. It take almost un
> > > > -noticeable time
> > > > (less than a sec) there.
> > > >
> > > > 2) When purgatory is executed then it re-calculates sha256 using same
> > > > routines
> > > > [2] on same binary data as that of case (1). But, now it takes 10-20
> > > > sec
> > > > (depending of size of binaries)?
> > > >
> > > > Why did not it take same time with O2 + D-cache enabled? I think, we
> > > > should be
> > > > able to achieve same time in second case as well. What is missing?
> >
> > I haven't benchmarked this, but:
> >
> > util_lib/sha256.c contains calls out to memcpy().
> > In your case 1, this will use the glibc version. In case 2, it will use
> > the version implemented in purgatory/string.c, which is a byte-by-byte
> > copy.
> >
>
> Yes, I agree that byte copy is too slow. But, memcpy() in sha256_update()
> will
> copy only few bytes (I think max 126 bytes). Most of the data will be
> processed
> using loop while( length >= 64 ){}, where we do not have any memcpy.So, I do
> not
> think that this would be causing such a difference.
>
> Could it be the case that I am not using perfect memory attributes while
> setting
> up identity mapping and enabling D-cache. My implementation is here:
> https://github.com/pratyushanand/kexec-tools/commit/8efdbc56b52f99a8a074edd0
> ddc519d7b68be82f
FWIW, purgatory is fast for me on PPC (sub-second), so between that (assuming
it's not due to some PPC-specific optimization) and the fact that you don't
see any improvement with cache, I'd guess there's something wrong with how
you're enabling caches.
-Scott
next prev parent reply other threads:[~2015-12-08 1:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1445469125.30908.105.camel@infradead.org>
[not found] ` <20151022031718.GB11227@dhcp-129-115.nay.redhat.com>
[not found] ` <20151022125012.GB20847@redhat.com>
[not found] ` <1445540891.30908.144.camel@infradead.org>
[not found] ` <1446703011.12676.83.camel@freescale.com>
[not found] ` <20151207114547.GE16406@dhcppc13.redhat.com>
2015-12-07 11:48 ` [PATCH] kexec: Add --lite option Pratyush Anand
2015-12-07 13:16 ` James Morse
2015-12-07 14:07 ` Pratyush Anand
2015-12-08 1:03 ` Scott Wood [this message]
2015-12-08 16:00 ` James Morse
2015-12-09 9:28 ` Pratyush Anand
2016-01-11 12:46 ` Pratyush Anand
2016-01-12 1:06 ` Simon Horman
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=1449536600.15946.102.camel@freescale.com \
--to=scottwood@freescale$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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