On Tue, Feb 24, 2009 at 06:22:00PM -0500, Will Woods wrote:
> On Fri, 2009-02-06 at 10:19 -0500, Bill Nottingham wrote:
> > Chris Lalancette (clala...@redhat.com) said:
> > > Do we know if anaconda is going to change
> > > to choose kernel-PAE for any machine with the PAE flag, regardless of
> > > the amount
> > > of memory?
> >
> > That's the plan - the patch should be pretty trivial.
>
> I haven't seen this patch yet. As far as I can tell, current anaconda
> installs the PAE kernel by default if isPaeAvailable() returns true[1].
>
> isPaeAvailable() uses the (somewhat odd) test of checking to see
> if /proc/iomem has a line where the start address is more than 32 bits
> long[2] - AFAICT it ignores the cpu flags entirely.
So the current rationale is 'if we have >4G of RAM, install the PAE kernel'.
It does that iomem poking because the kernel used at install time isn't capable
of seeing memory past 4G. So it's the best way of saying "do we have >4G?"
> In a discussion on IRC earlier today, cebbert mentioned that we might
> want a check more like:
>
> (PAE_flag and >=4GB RAM) or (PAE_flag and vmx_flag and >=1GB RAM)
>
> where vmx_flag is the flag for hardware virt stuff. Is this a good test?
or (PAE_flag and NX_flag)
> Some further questions:
> - Is a PAE kernel required for proper virt support?
Xen needs it.
> - Should we be using the PAE kernel *regardless* of memory size (as
> implied above) or do we want some memory requirements?
If we have NX (which anything made in the last few years will)
it's a performance win to use the hardware NX instead of the
segment limit hack we implemented in execshield.
There is a tradeoff for using larger page table entries, but it's
probably still a lot cheaper than the overhead of the seglimit hack.
Syscalls in particular should be a lot faster, as you get to
use the sysenter/sysexit instructions which are faster than using
the int 80h entrypoint. (The way the segment limits work is
incompatible with sysenter/sysexit).
Dave
--
http://www.codemonkey.org.uk
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
