On Thu, 2008-08-07 at 17:10 -0700, Jeremy Fitzhardinge wrote:
quoted text
> H. Peter Anvin wrote:
> > Jeremy Fitzhardinge wrote:
> >> H. Peter Anvin wrote:
> >>> The fixmap area should never have been made movable.  It's utter
> >>> braindamage.
> >>
> >> Shrug.  It's been like that for a couple of years now.  It was one of
> >> the very first paravirt-ops patches.  It wasn't controversial then,
> >> and nobody seems to have noticed since.
> >
> > The Linux kernel was never a paragon of perfection - it was never
> > meant to be.  Just because a bit of cruft went unnoticed into the
> > kernel doesn't mean we shouldn't fix it.
> 
> I don't really see what the issue is.
> 
> Fixmaps are primarily used for things that need to be mapped early
> before we can allocate address space dynamically.  They're predominantly
> used for boot-time init, and rarely on any performance-critical path.
> The only vaguely regular use a fixmap gets during runtime is poking at
> apics, and that's dominated by IO time, and kmap_atomic.  Statically,
> there's only 100 references in the kernel.  And it only affects 32-bit.
> 
> Having fixmaps at link-time fixed addresses would be nice, I suppose,
> but hardly worth going to vast effort over.

Using my interplanetary ideas, linking the fixmap at runtime would allow
optimal placement of the fixmap, any hypervisor areas, vmalloc, and
pkmap space.  That might allow one to increase the amount of lowmem
available for direct mapping depending on some platform variables such
as hypervisor reserved space, physical memory size, APIC present.. those
aren't known until boot time.  Actually, NCPUs is a good one, since we
require atomic kmap space dependent on NCPUs, which could be given back
to linear memory map.

That might actually be more worthwhile than link time fixed addresses.

Zach

--
unsubscribe notice
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/