Messages in this thread | | | Date | Wed, 3 Nov 1999 16:20:28 +0100 (MET) | From | Roman Zippel <> | Subject | Re: [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/
| |