Messages in this thread | | | Date | Thu, 11 Nov 1999 13:47:04 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: kiobuf using kernel pages |
| |
On Thu, 11 Nov 1999, Stephen C. Tweedie wrote:
> > by 'kernel virtual addresses' you do not mean the vmalloc() area > > exclusively, correct? > > No, they should basically be __va(physical page address). The kiobuf > tracks a table of "struct page *" to allow us to address memory beyond > 4G too.
yep, that is what i ment - apparently my change went in with the original highmem patchset.
basically only the 'user' portion of the highlevel kiobuf code is allowed to access or deal with virtual addresses, drivers should only ever deal with the 'page *' part, to get high memory case right.
> > Also, in my pagecache-in-highmem patches i've already got rid of the > > notion of storing virtual addresses in kiobufs, now it's only a 'struct > > page *' array instead of a virtual-address array. (will send it to you in > > a minute so you can see what i mean and we can sync up) > > Wrong move. You need the VA in the kiobuf in order to be able to map > things beyond the end of memory -- think of mapping a PCI video > framebuffer in a machine with less than 4G of memory. You don't have a > struct page * to point to those addresses.
[no, i didnt actually do it, ]
nevertheless i disagree a little bit with the current situation :) i believe we should keep the kiobuf interface (towards lowlevel drivers) 'struct page *'-only, for simplicity. The PCI-to-PCI DMA case is definitely worth worrying about, but we should rather extend the 'struct page *' notion instead of putting in a dual interface. There are two solutions i can think of: we could as well keep a separate mem_map for PCI (and generic bus) areas, to control usage. This means page_to_physaddr() type of conversion gets one more branch - no problem i think.
the other solution is to allow 'struct page *' to overflow above mem_map[]. Drivers which get such addresses have either be careful to not ever access contents directly (they should only use it to get the DMA address right), or they have to kmap it. We can change kmap to automatically map >=mem_map+max_mapnr pages to the correct _IO-space_ address.
> In order to be generic memory containers, kiobufs need both. There will > be some things you can't do unless you have the right type of page, but > the kiobuf should be able to contain any type.
yep - but there are other ways to achieve this goal, and storing physical+virtual is incorrect anyway, what about different IO spaces on certain architectures? _If_ we make it 'struct page *'-based, then we should make 'struct page *' (and its conversion routines) generic, not the other way around.
-- mingo
- 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/
| |