[lkml]   [2008]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1 of 8] x86: page.h: unify constants
On Mon, Jan 07, 2008 at 02:13:52PM -0800, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
>>> +
>>> +#define LARGE_PAGE_SIZE (_AC(1,UL) << PMD_SHIFT)
>>> +
>>> +#define HPAGE_SIZE (_AC(1,UL) << HPAGE_SHIFT)
>>> +#define HPAGE_MASK (~(HPAGE_SIZE - 1))
>> This will actually stop being the same soon with GB pages which
>> are only supported on 64bit.
> I was wondering about that. Will you always use GB pages, or will there be

When available and not disabled yes.

> two classes of huge pages, or will it be a runtime/compiletime config?

hugetlbfs will use different classes of huge pages depending on configuration
(I haven't posted those patches yet, only those for the direct mapping)
That all is expressed by different macros.

All runtime; I expect no CONFIGs involved, except that 32bit won't have
it since the architecture doesn't support it there.

>>> +
>>> +#ifdef CONFIG_X86_64
>>> +#define THREAD_ORDER 1
>>> +#define CURRENT_MASK (~(THREAD_SIZE-1))
>>> +
>>> +
>>> +
>>> +#define IRQSTACK_ORDER 2
>> This all seems hardly 64bit specific (except for THREAD_ORDER
>> but you can probably handle that in Kconfig or just get rid
>> of it for 32bit)
> They're only used by 64-bit at the moment, aren't they? Or are you

THREAD_ORDER should be used on 32bit too.

32bit also has the equivalent of irq stacks (quite similar)
and exception stacks (somewhat different). Currently they use
other defines, but they could use the same. Also i386 has varying
irqstack orders disabling them with 8k stacks, but that is something
that would be best dropped and irqstacks always used imho.

>> Also not 64bit specific
> It's use is 64-bit specific though, isn't it?

It might be, but it's not a 64bit specific concept.

>>> +#ifdef CONFIG_X86_PAE
>>> +#define __PHYSICAL_MASK_SHIFT 36
>> I originally added the PHYSICAL_MASK stuff to deal with masking off NX,
>> but I must admit it wasn't the best idea I ever had. It would be probably
>> better to just get rid of it and always mask off the high reserved flags
>> bit
>> explicitely. If you make that 0 then there should be no special
>> case for PAE.
> Hm, OK. I thought different 64-bit implementations might have different
> sized physical address spaces or something.

Yes they do, but hardcoding that doesn't make sense because it varies.
We already got CPUs with 36, 38, 40 and 48 bits phys size.

The only size that could be hard coded would be 52 bit (theoretical max), but
that also doesn't make sense if all we want to do is to mask off NX.

The only code that needs to know the real physical size is the MTRR
code, but that one gets it from CPUID as it should.


 \ /
  Last update: 2008-01-08 00:15    [W:0.040 / U:1.472 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site