All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Wool <vitalywool@gmail.com>
To: Wolfgang Denk <wd@denx.de>
Cc: "linuxppc-dev Development" <linuxppc-dev@ozlabs.org>,
	"Wolfgang Grandegger" <wg@denx.de>,
	"Németh Márton" <nm127@freemail.hu>
Subject: Re: Linux patches for XIP on MPC8xx?
Date: Wed, 24 Mar 2010 13:03:05 +0300	[thread overview]
Message-ID: <acd2a5931003240303r22fb2deat722b39e7f0d9a3dd@mail.gmail.com> (raw)
In-Reply-To: <20100323194401.0B7724C022@gemini.denx.de>

Hi,

> There were very few tests done with later kernel versions, and in all
> practical system configurations we tested we found that XIP did not
> give real benefits. Usually execution from flash was slower than when
> running from RAM, and even booting a (inevitably uncompressed) kernel
> from flash is typically slower than loading a compressed image to RUM
> and booting from there.

at some point we were testing some hybrid approaches for XIP and that
gave some nice results.

First of all, the kernel should not necessarily be uncompressed.
Because .data and friend sections are copied to RAM anyway, you can
compress them.

Besides, we had the "weird" XIP kernel version with only run-once code
run as XIP (like .initdata), copying the rest of kernel to RAM in the
background while initializing things, and it was really fast and
didn't produce performance penalty on the further execution.

> So except for some highly specialized applications (you may also call
> these "exotic" configurations) XIP for the Linux kernel does not make
> much sense to me.

Well, I'd put it this way: plain XIP usage is obsolete in the most
cases, but the idea is still viable if you apply it right :)

Thanks,
   Vitaly

      parent reply	other threads:[~2010-03-24 10:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23  6:55 Linux patches for XIP on MPC8xx? Németh Márton
2010-03-23 11:24 ` Wolfgang Grandegger
2010-03-23 19:44 ` Wolfgang Denk
2010-03-24  9:43   ` Benjamin Herrenschmidt
2010-03-24 10:03   ` Vitaly Wool [this message]

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=acd2a5931003240303r22fb2deat722b39e7f0d9a3dd@mail.gmail.com \
    --to=vitalywool@gmail.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nm127@freemail.hu \
    --cc=wd@denx.de \
    --cc=wg@denx.de \
    /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.