All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: William Lee Irwin III <wli@holomorphy.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: pud_bad vs pud_bad
Date: Thu, 05 Feb 2009 10:54:49 -0800	[thread overview]
Message-ID: <498B35F9.601@goop.org> (raw)
In-Reply-To: <20090205184355.GF5661@elte.hu>

Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
>   
>> I'm looking at unifying the 32 and 64-bit versions of pud_bad.
>>
>> 32-bits defines it as:
>>
>> static inline int pud_bad(pud_t pud)
>> {
>> 	return (pud_val(pud) & ~(PTE_PFN_MASK | _KERNPG_TABLE | _PAGE_USER)) != 0;
>> }
>>
>> and 64 as:
>>
>> static inline int pud_bad(pud_t pud)
>> {
>> 	return (pud_val(pud) & ~(PTE_PFN_MASK | _PAGE_USER)) != _KERNPG_TABLE;
>> }
>>
>>
>> I'm inclined to go with the 64-bit version, but I'm wondering if there's 
>> something subtle I'm missing here.
>>     
>
> Why go with the 64-bit version? The 32-bit check looks more compact and 
> should result in smaller code.
>   

Well, its stricter.  But I don't really understand what condition its 
actually testing for.

    J

WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: William Lee Irwin III <wli@holomorphy.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: pud_bad vs pud_bad
Date: Thu, 05 Feb 2009 10:54:49 -0800	[thread overview]
Message-ID: <498B35F9.601@goop.org> (raw)
In-Reply-To: <20090205184355.GF5661@elte.hu>

Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
>   
>> I'm looking at unifying the 32 and 64-bit versions of pud_bad.
>>
>> 32-bits defines it as:
>>
>> static inline int pud_bad(pud_t pud)
>> {
>> 	return (pud_val(pud) & ~(PTE_PFN_MASK | _KERNPG_TABLE | _PAGE_USER)) != 0;
>> }
>>
>> and 64 as:
>>
>> static inline int pud_bad(pud_t pud)
>> {
>> 	return (pud_val(pud) & ~(PTE_PFN_MASK | _PAGE_USER)) != _KERNPG_TABLE;
>> }
>>
>>
>> I'm inclined to go with the 64-bit version, but I'm wondering if there's 
>> something subtle I'm missing here.
>>     
>
> Why go with the 64-bit version? The 32-bit check looks more compact and 
> should result in smaller code.
>   

Well, its stricter.  But I don't really understand what condition its 
actually testing for.

    J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-02-05 18:55 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05 18:23 pud_bad vs pud_bad Jeremy Fitzhardinge
2009-02-05 18:23 ` Jeremy Fitzhardinge
2009-02-05 18:43 ` Ingo Molnar
2009-02-05 18:43   ` Ingo Molnar
2009-02-05 18:54   ` Jeremy Fitzhardinge [this message]
2009-02-05 18:54     ` Jeremy Fitzhardinge
2009-02-05 19:10     ` Ingo Molnar
2009-02-05 19:10       ` Ingo Molnar
2009-02-05 19:26       ` Jeremy Fitzhardinge
2009-02-05 19:26         ` Jeremy Fitzhardinge
2009-02-05 19:31         ` Ingo Molnar
2009-02-05 19:31           ` Ingo Molnar
2009-02-05 19:38       ` Hugh Dickins
2009-02-05 19:38         ` Hugh Dickins
2009-02-05 19:49         ` Ingo Molnar
2009-02-05 19:49           ` Ingo Molnar
2009-02-05 19:58           ` wli
2009-02-05 19:58             ` wli
2009-02-05 20:14             ` Hugh Dickins
2009-02-05 20:14               ` Hugh Dickins
2009-02-05 20:56               ` wli
2009-02-05 20:56                 ` wli
2009-02-05 21:09                 ` Hugh Dickins
2009-02-05 21:09                   ` Hugh Dickins
2009-02-05 20:12           ` Hugh Dickins
2009-02-05 20:12             ` Hugh Dickins
2009-02-05 20:42         ` Jeremy Fitzhardinge
2009-02-05 20:42           ` Jeremy Fitzhardinge
2009-02-05 20:51           ` Hugh Dickins
2009-02-05 20:51             ` Hugh Dickins
2009-02-05 21:05             ` Jeremy Fitzhardinge
2009-02-05 21:05               ` Jeremy Fitzhardinge
2009-02-05 21:50               ` Ingo Molnar
2009-02-05 21:50                 ` Ingo Molnar
2009-02-05 22:07                 ` Jeremy Fitzhardinge
2009-02-05 22:07                   ` Jeremy Fitzhardinge
2009-02-05 23:42                   ` Ingo Molnar
2009-02-05 23:42                     ` Ingo Molnar
2009-02-06  0:08                     ` Jeremy Fitzhardinge
2009-02-06  0:08                       ` Jeremy Fitzhardinge
2009-02-06  0:50                       ` Ingo Molnar
2009-02-06  0:50                         ` Ingo Molnar
2009-02-05 20:57           ` Ingo Molnar
2009-02-05 20:57             ` 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=498B35F9.601@goop.org \
    --to=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=wli@holomorphy.com \
    /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.