Re: [Fastboot] Re: [PATCH] Kexec: Remove order

["Magnus Damm" <magnus.damm@gmail.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/