lkml.org 
[lkml]   [2009]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC] x86: add brk allocation for very, very early allocations
Jeremy Fitzhardinge wrote:
> I'd like to add a mechanism like this so I can dynamically allocate some
> Xen-related structures, rather than statically allocating them in the bss,
> both so that Xen has less overhead when it isn't being used, and so I can
> scale better to things like memory size.
>
> I think this is more widely useful; it would supplant dmi_alloc_data[], for
> example, and I'm sure there's other cases.
>
> This is fundimentally the same as head_32.S's extension of the bss to build
> the initial kernel mapping, but 64-bit doesn't currently do anything
> analogous
> to this.
>
> Unfortunately when I use this code as-is I'm getting crashes when the slab
> allocator starts up. I think this is all correct, but I'm wondering if
> there's something I'm overlooking which is broken in principle.

First of all, I like the concept. As far as getting crashes, I suspect
what you're finding is some use of this type of extended memory space
that just isn't documented. I would try this in a simulator, setting a
watchpoint on _end to see if you get any hits before the slab allocator
starts.

-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.



\
 
 \ /
  Last update: 2009-02-27 19:49    [W:0.057 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site