Hi there, are huge TLB pages always physically continous in memory? What does follow_hugetlb_page do exactly? I simply don't understand what the code does. I would like to build up a simplified get_user_pages_sgl() to build a scatter gather list from user space adresses. If I want to coalesce physically continous pages (if they are also virtually continious) anyway, can I write up a simplified follow_hugetlb_page_sgl() function which handles the huge page really as only one page? Motivation: Currently doing scatter gather DMA of user pages requires THREE runs over the pages and I would like to save at least the second one and possibly shorten the third one. The three steps required: 1) get_user_pages() to obtain the pages and lock them in page_cache 2) translate the vector of pointers to struct page to a vector of struct scatterlist 3) pci_map_sg() a decent amount[1], DMA it, wait for completion or abortion, pci_unmap_sg() it and start again with the remainder Step 2) could be eliminated completely and also the allocation of the temporary vector of struct page. Step 3) could be shortend, if I coalesce physically continous ranges into a single scatterlist entry with just a ->length bigger than PAGE_SIZE. I know that this is only worth it on architectures, where physical address == bus address. As each step is a for() loop and should be considered running on more than 1MB worth of memory, I see significant improvements. Without supporting huge TLB pages, I only add 700 bytes to the kernel while simply copying get_user_pages() into a function, which takes an vector of struct scatterlist instead of struct page. This sounds a promising tradeoff for a first time implementation. Patch attached. No users yet, but they will follow. First candidate is the v4l DMA stuff. Regards Ingo Oeser [1] How much can I safely map on the strange architectures, where this is a limited? AFAIK there is no value or function telling me how far I can go. -- Science is what we can tell a computer. Art is everything else. --- D.E.Knuth