From: "Magnus Damm" <magnus.damm@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Magnus Damm" <magnus@valinux.co.jp>,
fastboot@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] Re: [PATCH] Kexec: Remove order
Date: Thu, 13 Apr 2006 15:21:51 +0900 [thread overview]
Message-ID: <aec7e5c30604122321p2bedb370l945009ccdb725bac@mail.gmail.com> (raw)
In-Reply-To: <m164le6rcg.fsf@ebiederm.dsl.xmission.com>
On 4/13/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Magnus Damm <magnus@valinux.co.jp> writes:
>
> > Kexec: Remove order
> >
> > This patch replaces kexec n-order allocation code with 0-order only.
> >
> > Almost all kexec allocations are 0-order pages already, with the exception of
> > some x86_64 specific code that requests two physically contiguous pages.
> >
> > These two physically contiguous pages are easily replaced with two separate
> > pages. The second page is kept in an architecture specific pointer that is
> > added to struct kimage.
> >
> > Using 0-order allocations only greatly simplifies kexec porting work to
> > the Xen hypervisor.
>
> NACK.
>
> It is a big intrusive patch that makes it impossible to
> port to some architectures, and it obscures what you
> are really trying to do which is fix x86_64.
When I had a working x86_64 that didn't use 2 contiguous pages there
were no other users left of non-0 order allocations, so I thought it
would be better to remove the unused code than to keep it.
But you probably have some unmerged code that depends on that functionality.
> Feel free to fix x86_64, to use only page sized allocates.
I will. But first - questions:
Should KEXEC_CONTROL_CODE_SIZE be left in even if it's always 4096?
Do you like how I added image->arch_private?
> Until I see a reasonable argument that none of the architectures
> currently supported by the linux kernel would need a multi order
> allocation for a kexec port am I interested in removing support.
I argue that it is quite pointless to have code to support N-order
allocations that no one is using. Especially since the code is more
complex and it may be harder for the buddy allocator to fulfill
N-order allocations compared to 0-order allocations.
And on top of the reasons above I'd like to stay away from N-order
allocations because Xen doesn't guarantee that (pseudo-)physical pages
handled out by the buddy allocator are contiguous.
> As I recall the alpha had an architectural need for a 32KB
> allocation or something like that.
Oh. So if someone is working on kexec for alpha I guess we need
N-order allocations, right?
Thanks for your comments!
/ magnus
next prev parent reply other threads:[~2006-04-13 6:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 2:59 Magnus Damm
2006-04-13 4:18 ` Eric W. Biederman
2006-04-13 6:21 ` Magnus Damm [this message]
2006-04-13 10:01 ` [Fastboot] " Eric W. Biederman
2006-04-14 0:57 ` Magnus Damm
2006-04-13 19:53 ` Christoph Lameter
2006-04-14 1:01 ` Magnus Damm
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=aec7e5c30604122321p2bedb370l945009ccdb725bac@mail.gmail.com \
--to=magnus.damm@gmail.com \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus@valinux.co.jp \
/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
all inboxes | Powered by JetHome®