On 02/08/2012 01:28 PM, Dave Hansen wrote: > On 02/08/2012 09:53 AM, Nitin Gupta wrote: >> vmap() is not just slower but also does memory allocations at various >> places. Under memory pressure, this may cause failure in reading a >> stored object just because we failed to map it. Also, it allocates VA >> region each time its called which is a real big waste when we can simply >> pre-allocate 2 * PAGE_SIZE'ed VA regions (per-cpu). > > Yeah, vmap() is a bit heavy-handed. I'm just loathe to go mucking > around in the low-level pagetables too much. Just seems like there'll > be a ton of pitfalls, like arch-specific TLB flushing, and it _seems_ > like one of the existing kernel mechanisms should work. > > I guess if you've exhaustively explored all of the existing kernel > mapping mechanisms and found none of them to work, and none of them to > be in any way suitably adaptable to your use, you should go ahead and > roll your own. I guess you do at least use alloc_vm_area(). What made > map_vm_area() unsuitable for your needs? If you're remapping, you > should at least be guaranteed not to have to allocate pte pages. > map_vm_area() needs 'struct vm_struct' parameter but for mapping kernel allocated pages within kernel, what should we pass here? I think we can instead use map_kernel_range_noflush() -- surprisingly unmap_kernel_range_noflush() is exported but this one is not. Nitin _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
