On Sat, 2007-02-17 at 21:29 -0800, Jeremy Fitzhardinge wrote: > I'm looking at making all architectures export a vmalloc_sync_all() > function, so that generic code can be sure that a particular vmalloc > mapping is present in all address spaces. I need this to implement a > function to reserve a chunk of vmalloc address space complete with > constructed pagetables, but without allocating any actual data pages. > > On i386 with PAE, this is not necessary because the kernel's mappings > are shared between all processes anyway, so it would be a no-op. > However, non-PAE i386 has a separate kernel mapping for each process, > and so needs to sync them - typically lazily on faults, but > vmalloc_sync_all exists to allow mass syncing when required. > > What other architectures would require syncing of vmalloc mappings, and > what architectures would implement it as a no-op?
Er, but there are fundamental assumptions that vmalloc_sync_all() makes that simply aren't true on other architectures. Really, it's an artifact of the Intel x86 processor's inability to flush by %cr3, so we try to keep the kernel mappings alive in a process so that a sys call and return doesn't do a full TLB flush ... and thus, because we have a hidden piece of kernel in userspace, we get the HIGHMEM issues. A substantial number of other architectures do have a selective TLB flush, so a lot operate with a fully separated kernel and user space, and thus vmalloc mappings appear only in the single kernel address space and nowhere else. Could you elaborate on exactly what you think you need vmalloc_sync_all() exported for ... your explanation of a reserved vmalloc range sounds reasonable, but should in no way depend on vmalloc_sync_all(). It really sounds like this should be an arch specific function so the architectures can decide the implementation details. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/