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
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:22 EST