lkml.org 
[lkml]   [1999]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] bootmem-2.3.25-A0
Hi,

On Wed, 3 Nov 1999, Ingo Molnar wrote:

> > > > This is just Ingo being bad. He should have used virt_to_phys() and
> > > > friends, not __pa().
> >
> > IMHO, __pa should not be the same as virt_to_phys(). [...]
>
> i've fixed this already in my tree (patch attached) - but i do not think
> this should make any difference. bootmem.c does not deal with vmalloced or
> ioremapped memory, so __pa/__va should be identical to virt_to_phys /
> phys_to_virt.

But this was never the case on m68k and currently isn't true for arm.

> there is a single place where bootmem.c uses virt_to_phys, and thats a
> constant address (MAX_DMA_ADDRESS). I'd be surprised if there was any
> difference between virt_to_phys() and __pa() in this case. There were
> several uses of __va() in bootmem.c - can there be any theoretical
> difference between __va() and phys_to_virt()?

The problem is how to behave for memory that isn't mapped, if you only add
on offset, this isn't a big problem, but on m68k we map everything
together, so we have a continous memory area and the memory conversion
isn't a simple offset anymore. This is mostly only a problem for
remap_page_range() where you have to decide on the physical address,
whether you map the range into the userspace or not.
Another problem is reading(writing) from /dev/mem, from where shall I
read(write) when the page isn't mapped?

> Niibe Yutaka (the SH maintainer) noticed this 'too big bitmap and memory
> map' problem too, and he promised to send patches for this in a few days.
> (it's a bit hard to test this on x86) It's not really a problem with the
> bootmem.c bitmap (that one is getting freed after bootup anyway), the real
> problem is mem_map[], which can get unnecesserily big if there are too
> many 'holes' in the physical memory layout.

We solve this by mapping everything together and using the virtual address
as index into mem_map. Another solution is PageSkip as it's used on Sparc,
but here you need to know a bit about the possible memory locations,
otherwise you have to fall back to normal mapping and I suspect problems
with PageSkip, since most code assumes a continues valid mem_map, what
isn't true with PageSkip.

bye, Roman


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.092 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site