Messages in this thread | | | Date | Thu, 13 Apr 2006 15:21:51 +0900 | From | "Magnus Damm" <> | Subject | Re: [Fastboot] Re: [PATCH] Kexec: Remove order |
| |
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/
| |