public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andi Kleen <ak@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Glauber de Oliveira Costa <glommer@gmail.com>,
	Jan Beulich <jbeulich@novell.com>
Subject: Re: [PATCH 1 of 8] x86: page.h: unify constants
Date: Mon, 07 Jan 2008 14:13:52 -0800	[thread overview]
Message-ID: <4782A420.30807@goop.org> (raw)
In-Reply-To: <20080107171712.GE2998@bingen.suse.de>

Andi Kleen wrote:
>> +
>> +#define LARGE_PAGE_SIZE		(_AC(1,UL) << PMD_SHIFT)
>> +#define LARGE_PAGE_MASK		(~(LARGE_PAGE_SIZE-1))
>> +
>> +#define HPAGE_SHIFT		PMD_SHIFT
>> +#define HPAGE_SIZE		(_AC(1,UL) << HPAGE_SHIFT)
>> +#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
>> +#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>>     
>
> 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 two classes of huge pages, or will it be a runtime/compiletime config?

>> +
>> +#ifdef CONFIG_X86_64
>> +#define THREAD_ORDER	1
>> +#define THREAD_SIZE  (PAGE_SIZE << THREAD_ORDER)
>> +#define CURRENT_MASK (~(THREAD_SIZE-1))
>> +
>> +#define EXCEPTION_STACK_ORDER 0
>> +#define EXCEPTION_STKSZ (PAGE_SIZE << EXCEPTION_STACK_ORDER)
>> +
>> +#define DEBUG_STACK_ORDER (EXCEPTION_STACK_ORDER + 1)
>> +#define DEBUG_STKSZ (PAGE_SIZE << DEBUG_STACK_ORDER)
>> +
>> +#define IRQSTACK_ORDER 2
>> +#define IRQSTACKSIZE (PAGE_SIZE << IRQSTACK_ORDER)
>>     
>
> 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 
suggesting 32-bit could use them too?  There's no corresponding 
definitions on the 32-bit side at the moment.

>> +#define __PHYSICAL_START	CONFIG_PHYSICAL_START
>>     
>
> Also not 64bit specific
>   

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

>> +#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.


    J

  reply	other threads:[~2008-01-07 22:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-03 20:10 [PATCH 0 of 8] x86: unify asm/page.h Jeremy Fitzhardinge
2008-01-03 20:10 ` [PATCH 1 of 8] x86: page.h: unify constants Jeremy Fitzhardinge
2008-01-07 17:17   ` Andi Kleen
2008-01-07 22:13     ` Jeremy Fitzhardinge [this message]
2008-01-07 23:13       ` Andi Kleen
2008-01-08  1:11         ` Jeremy Fitzhardinge
2008-01-03 20:10 ` [PATCH 2 of 8] x86: page.h: unify page copying and clearing Jeremy Fitzhardinge
2008-01-03 20:11 ` [PATCH 3 of 8] x86: add _AT() macro to conditionally cast Jeremy Fitzhardinge
2008-01-03 20:11 ` [PATCH 4 of 8] x86: page.h: move and unify types for pagetable entry definitions Jeremy Fitzhardinge
2008-01-03 20:11 ` [PATCH 5 of 8] x86: page.h: move pa and va related things Jeremy Fitzhardinge
2008-01-03 20:11 ` [PATCH 6 of 8] x86: page.h: move remaining bits and pieces Jeremy Fitzhardinge
2008-01-03 20:11 ` [PATCH 7 of 8] x86: page.h: move things back to their own files Jeremy Fitzhardinge
2008-01-03 20:11 ` [PATCH 8 of 8] x86/efi: fix improper use of lvalue Jeremy Fitzhardinge
2008-01-04  7:38 ` [PATCH 0 of 8] x86: unify asm/page.h Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4782A420.30807@goop.org \
    --to=jeremy@goop.org \
    --cc=ak@suse.de \
    --cc=glommer@gmail.com \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox