linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Zippel <zippel@linux-m68k.org>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Rik van Riel <riel@conectiva.com.br>,
	Samuel Ortiz <sortiz@dbear.engr.sgi.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH] rmap 13a
Date: Thu, 09 May 2002 17:36:22 +0200	[thread overview]
Message-ID: <3CDA9776.776CB406@linux-m68k.org> (raw)
In-Reply-To: <20020509140943.GP15756@holomorphy.com>

Hi,

William Lee Irwin III wrote:

> I stated starting at 0 as one of the preconditions for page - mem_map
> based calculations. The only missing piece of information is the
> starting address, which is not very difficult to take care of so as
> to relax this invariant (compilers *should* optimize out 0). Hence,
> 
> static inline void *page_address(struct page *page)
> {
>         return __va(MEM_START + ((page - mem_map) << PAGE_SHIFT));
> }

There is no generic MEM_START, but there is PAGE_OFFSET. Why don't you
want to use this instead?

> Unfortunately there isn't a CONFIG_MEM_STARTS_AT_ZERO or a MEM_START.

And it's not needed, why should the vm care about the physical memory
location?

> To date I've gotten very few and/or very unclear responses from arch
> maintainers. I'm very interested in getting info from arches such as
> this but have had approximately zero input along this front thus far.
> Do you have any suggestions as to a decent course of action here? My
> first thought is a small set of #defines in include/asm-*/param.h or
> some appropriate arch header.

What do you want to define there?

> I believe the real issue is that architectures don't yet export enough
> information to select the version they really want. There just aren't
> enough variations on this theme to warrant doing this in arch code, and
> I think I got some consensus on that by the mere acceptance of the
> patch to remove ->virtual in most instances.

The basic mechanism is often the same, that's true. The problem is to
allow the archs an efficient conversion. Only the arch specific code
knows how the memory is laid out and can use this information to
optimize the conversion at compile time by making some of the variables
constant. As soon as you have managed to generalize this, I'm sure
highmem will be the only special case left you have to deal with.

> If we can agree on this much then can we start pinning down a more
> precise method of selecting the method of address calculation? I'm
> very interested in maintaining this code and making it suitable for
> all architectures.

Why is it so important to move it out of the arch code? The simple case
is trivial enough to be copied around or maybe put some templates into
asm-generic, but I'd prefer to leave the archs complete control about
this.

bye, Roman
--
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/

  reply	other threads:[~2002-05-09 15:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-07  2:17 Rik van Riel
2002-05-07 17:37 ` Christoph Hellwig
2002-05-07 18:03   ` William Lee Irwin III
2002-05-08 11:06   ` Samuel Ortiz
2002-05-08 11:13     ` William Lee Irwin III
2002-05-08 13:40     ` Rik van Riel
2002-05-08 18:21   ` Roman Zippel
2002-05-08 21:34     ` William Lee Irwin III
2002-05-08 22:34       ` Roman Zippel
2002-05-08 22:42         ` William Lee Irwin III
2002-05-08 22:50           ` William Lee Irwin III
2002-05-08 23:26           ` Roman Zippel
2002-05-09  1:29             ` William Lee Irwin III
2002-05-09 12:33               ` Roman Zippel
2002-05-09 14:09                 ` William Lee Irwin III
2002-05-09 15:36                   ` Roman Zippel [this message]
2002-05-09 17:42                     ` William Lee Irwin III
2002-05-09 21:45                       ` Roman Zippel
2002-05-09 23:13                         ` William Lee Irwin III
2002-05-10 11:37                           ` Roman Zippel
2002-05-10 16:28                             ` William Lee Irwin III
2002-05-10 19:48                               ` Roman Zippel
2002-05-08 21:50     ` William Lee Irwin III

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=3CDA9776.776CB406@linux-m68k.org \
    --to=zippel@linux-m68k.org \
    --cc=hch@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=sortiz@dbear.engr.sgi.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox