lkml.org 
[lkml]   [2005]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH, experimental] i386 Allow the fixmap to be relocated at boot time
Chris Wright wrote:

>* Zachary Amsden (zach@vmware.com) wrote:
>
>
>>This most curious patch allows the fixmap on i386 to be unfixed. The
>>result is that we can create a dynamically sizable hole at the top of
>>kernel linear address space. I know at least some virtualization
>>developers are interested in being able to achieve this to achieve
>>run-time sizing of a hole in which a hypervisor can live, or at least to
>>test out the performance characteristics of different sized holes.
>>
>>
>
>I've done it simpler with keeping it fixed but defined by the subarch.
>Patch is stupid simple (and untested). Do you think there's a huge gain
>for dynamically sizing?
>

Your patch looks good, although the minimal change to subarch is to
merely have __FIXADDR_TOP defined by the sub-architecture. Is there any
additional benefit to moving the fixmaps into the subarch - i.e. moving
subarch-specific pieces out of mach-default?

I guess there is. For example include/asm-i386/mach-visws/mach_fixmap.h
could do this:

#define SUBARCH_FIXMAPS \
FIX_CO_CPU, /* Cobalt timer */ \
FIX_CO_APIC, /* Cobalt APIC Redirection Table */ \
FIX_LI_PCIA, /* Lithium PCI Bridge A */ \
FIX_LI_PCIB, /* Lithium PCI Bridge B */

Then include/asm-i386/fixmap.h includes <mach_fixmap.h>, for which the
default is an empty define for SUBARCH_FIXMAPS.

And then you don't have to maintain the list of common fixmaps across
the sub-architecture layer or uglify the top level fixmaps with SGI
Visual Workstation support.

Also, it seems reasonable that people may want to poke holes in high
linear space for other hypervisor projects, research, or performance
reasons without having to build a custom sub-architecture just for
that. So I think there is some benefit to making the hole size a
general configurable option (with defaults depending on the sub-arch you
select).

I have no idea if the dynamic sizing has any performance impact yet, but
it may be a big win in terms of flexibility. I would be curious to hear
more from the Xen core team (I know Ian mentioned he would like to try
this out at one point in time).

Zach
-
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/

\
 
 \ /
  Last update: 2005-08-06 02:15    [W:0.169 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site