Re: [PATCH] rmap 13a

[William Lee Irwin III <wli@holomorphy.com>]

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));
>> }

On Thu, May 09, 2002 at 05:36:22PM +0200, Roman Zippel wrote:
> There is no generic MEM_START, but there is PAGE_OFFSET. Why don't you
> want to use this instead?

MEM_START would be the lowest physical address, not the lowest virtual.
__va(PAGE_OFFSET + ((page - mem_map) << PAGE_SHIFT)) would yield
garbage... Perhaps __pa(PAGE_OFFSET) would work while relaxing only the
"memory starts at 0" precondition? It should come out to 0 for the
architectures with memory starting at 0, and the other preconditions
guarantee that it's the lowest physical, but that breaks if the lowest
physical isn't mapped to PAGE_OFFSET...

William Lee Irwin III wrote:
>> Unfortunately there isn't a CONFIG_MEM_STARTS_AT_ZERO or a MEM_START.

On Thu, May 09, 2002 at 05:36:22PM +0200, Roman Zippel wrote:
> And it's not needed, why should the vm care about the physical memory
> location?

VM is about translating virtual to physical, and so it must know
something resembling the physical address of a page just to edit PTE's?


William Lee Irwin III wrote:
>> 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.

On Thu, May 09, 2002 at 05:36:22PM +0200, Roman Zippel wrote:
> What do you want to define there?

(1) ARCH_SLOW_ALU
	Address calculation doesn't win on some CPU's with ridiculously
	slow ALU's (well, slow relative to memory fetch)
(2) ARCH_DENSEMAPS_ZONES (probably better to define it elsewhere)
	MAP_NR_DENSE() makes address calculation schemes somewhat more
	expensive
(3) ARCH_REMAPS_DISCONTIG
	__va() and __pa() may do strange things when physical memory is
	mapped in a strange ways for virtual contiguity, don't mess
	with these guys
(4) ARCH_TRIVIAL_MEMORY_LAYOUT
	We're the super-easy case that nobody complains about =)


William Lee Irwin III wrote:
>> 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.

On Thu, May 09, 2002 at 05:36:22PM +0200, Roman Zippel wrote:
> 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.

This sounds like an important direction I should investigate then. I've
already got a notion of how highmem could be dealt with (c.f. indexing
into kmap pool post). I'll have to dig around to see what architectures
export and see what needs to be standardized for an address calculation 
scheme based on constructing the address with the help of those constants.


On Thu, May 09, 2002 at 05:36:22PM +0200, Roman Zippel wrote:
>> 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.

On Thu, May 09, 2002 at 05:36:22PM +0200, Roman Zippel wrote:
> 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.

mem_map was bloated to the point where highmem machines couldn't get
enough ZONE_NORMAL to boot. Control definitely needs to be exerted over
the space consumption of mem_map, and killing ->virtual wherever/whenever
possible is a large part of that. I even have some evidence that what
control of that space consumption there is now may still be insufficient.

asm-generic has the small problem that it divorces the format of struct
page from the definition of page_address(). Also, it shouldn't really be
optional; the VM should be given enough information to do the right thing.

Cheers,
Bill
--
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/