All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Roman Zippel <zippel@linux-m68k.org>,
	Andrew Morton <akpm@osdl.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [patch 2/2] convert s390 page handling macros to functions v3
Date: Mon, 11 Sep 2006 06:22:01 +0200	[thread overview]
Message-ID: <20060911042201.GA8379@osiris.ibm.com> (raw)
In-Reply-To: <1157905518.26324.83.camel@localhost.localdomain>

On Sun, Sep 10, 2006 at 09:25:18AM -0700, Dave Hansen wrote:
> On Sun, 2006-09-10 at 15:08 +0200, Heiko Carstens wrote:
> > 
> > +static inline int page_test_and_clear_dirty(struct page *page)
> > +{
> > +       unsigned long physpage = __pa((page - mem_map) << PAGE_SHIFT);
> > +       int skey = page_get_storage_key(physpage); 
> 
> This has nothing to do with your patch at all, but why is 'page -
> mem_map' being open-coded here?

I just changed the defines to functions without thinking about this.. :)
 
> I see at least a couple of page_to_phys() definitions on some
> architectures.  This operation is done enough times that s390 could
> probably use the same treatment.

Yes, even s390 has page_to_phys() as well. But why is it in io.h? Seems
like this is inconsistent across architectures. Also in quite a few
architectures the define looks like this:

#define page_to_phys(page)	((page - mem_map) << PAGE_SHIFT)

A pair of braces is missing around page. Yet another possible subtle bug...

> It could at least use a page_to_pfn() instead of the 'page - mem_map'
> operation, right?

Yes, I will address that in a later patch. Shouldn't stop this one from
being merged, if there aren't any other objections.
Thanks for pointing this out!

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Roman Zippel <zippel@linux-m68k.org>,
	Andrew Morton <akpm@osdl.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [patch 2/2] convert s390 page handling macros to functions v3
Date: Mon, 11 Sep 2006 06:22:01 +0200	[thread overview]
Message-ID: <20060911042201.GA8379@osiris.ibm.com> (raw)
In-Reply-To: <1157905518.26324.83.camel@localhost.localdomain>

On Sun, Sep 10, 2006 at 09:25:18AM -0700, Dave Hansen wrote:
> On Sun, 2006-09-10 at 15:08 +0200, Heiko Carstens wrote:
> > 
> > +static inline int page_test_and_clear_dirty(struct page *page)
> > +{
> > +       unsigned long physpage = __pa((page - mem_map) << PAGE_SHIFT);
> > +       int skey = page_get_storage_key(physpage); 
> 
> This has nothing to do with your patch at all, but why is 'page -
> mem_map' being open-coded here?

I just changed the defines to functions without thinking about this.. :)
 
> I see at least a couple of page_to_phys() definitions on some
> architectures.  This operation is done enough times that s390 could
> probably use the same treatment.

Yes, even s390 has page_to_phys() as well. But why is it in io.h? Seems
like this is inconsistent across architectures. Also in quite a few
architectures the define looks like this:

#define page_to_phys(page)	((page - mem_map) << PAGE_SHIFT)

A pair of braces is missing around page. Yet another possible subtle bug...

> It could at least use a page_to_pfn() instead of the 'page - mem_map'
> operation, right?

Yes, I will address that in a later patch. Shouldn't stop this one from
being merged, if there aren't any other objections.
Thanks for pointing this out!

--
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:[~2006-09-11  4:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-08 11:17 [patch 1/2] own header file for struct page Heiko Carstens
2006-09-08 11:17 ` Heiko Carstens, Heiko Carstens
2006-09-08 16:46 ` Andrew Morton
2006-09-08 16:46   ` Andrew Morton
2006-09-08 18:33   ` Heiko Carstens
2006-09-08 18:33     ` Heiko Carstens
2006-09-08 19:06     ` Andrew Morton
2006-09-08 19:06       ` Andrew Morton
2006-09-08 19:47       ` [patch 1/2] own header file for struct page v2 Heiko Carstens
2006-09-08 19:47         ` Heiko Carstens, Heiko Carstens
2006-09-08 19:48       ` [patch 2/2] convert s390 page handling macros to functions v2 Heiko Carstens
2006-09-08 19:48         ` Heiko Carstens, Heiko Carstens
2006-09-09 21:05 ` [patch 1/2] own header file for struct page Roman Zippel
2006-09-09 21:05   ` Roman Zippel
2006-09-10  7:51   ` Heiko Carstens
2006-09-10  7:51     ` Heiko Carstens
2006-09-10 13:07   ` [patch 1/2] own header file for struct page v3 Heiko Carstens
2006-09-10 13:07     ` Heiko Carstens, Heiko Carstens
2006-09-10 13:08   ` [patch 2/2] convert s390 page handling macros to functions v3 Heiko Carstens
2006-09-10 13:08     ` Heiko Carstens, Heiko Carstens
2006-09-10 16:25     ` Dave Hansen
2006-09-10 16:25       ` Dave Hansen
2006-09-11  4:22       ` Heiko Carstens [this message]
2006-09-11  4:22         ` Heiko Carstens

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=20060911042201.GA8379@osiris.ibm.com \
    --to=heiko.carstens@de.ibm.com \
    --cc=akpm@osdl.org \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=zippel@linux-m68k.org \
    /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.