[LSF/MM ATTEND] gup/dma, file-backed memory, and THP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I'd like to attend LSF/MM, in particular the following topics and areas:

-- The get_user_pages()+DMA problem. Here, the page tracking technique
seems fairly well settled. I've posted an RFC for the page tracking [1], 
and also posted the first two put_user_pages() patches as non-RFC [2].

However, the interactions with filesystems are still under active 
discussion. That is, what to do when clear_page_dirty_for_io() lands 
on a page that has an active get_user_pages() caller: this is still
being discussed.

I think there are viable solutions and we're getting there, and I
*really* hope we might actually converge on an approach at this 
conference. Although, it's very awkward that Dave Chinner can't make it!

-- Amir Goldstein proposed a "Sharing file backed pages" TOPIC, and 
this is very closely related to the gup/dma issues above, so I want
to be there for that. And generally, get_user_pages and file system
interactions are of course thing I want to be involved in lately.

This next one was partially covered in Zi Yan's ATTEND request. But 
his focus was slightly different, so I wanted to come at it from a
slightly different perspective, which is:

-- THP and huge pages in general. It turns out that some high-thread-count
devices (GPUs, of course, but also various AI chips and FPGA solutions)
do much, much better with 2MB pages. In fact, it's so important that
we've been expecting to be forced to use hugetlbfs, in order to be
guaranteed those size pages. However, it would be better if the system
could instead, reliably and efficiently provide huge pages, to the point
that a GPU-like device could more or less always get a 2 MB page when 
it needs it.

Also, perhaps a minor point: there don't seem to be kernel-side allocators
for huge pages, but in order for device drivers to use them, it seems like 
that would be required.

[1] https://lore.kernel.org/r/20190204052135.25784-1-jhubbard@xxxxxxxxxx

[2] https://lore.kernel.org/r/20190208075649.3025-1-jhubbard@xxxxxxxxxx

thanks,
-- 
John Hubbard
NVIDIA

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux