All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.