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/