On Wed, May 6, 2015 at 1:05 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > In preparation for converting struct bio_vec to carry a __pfn_t instead > of struct page. > > This change is prompted by the desire to add in-kernel DMA support > (O_DIRECT, hierarchical storage, RDMA, etc) for persistent memory which > lacks struct page coverage. > > Alternatives: > > 1/ Provide struct page coverage for persistent memory in DRAM. The > expectation is that persistent memory capacities make this untenable > in the long term. > > 2/ Provide struct page coverage for persistent memory with persistent > memory. While persistent memory may have near DRAM performance > characteristics it may not have the same write-endurance of DRAM. > Given the update frequency of struct page objects it may not be > suitable for persistent memory. > > 3/ Dynamically allocate struct page. This appears to be on the order > of the complexity of converting code paths to use __pfn_t references > instead of struct page, and the amount of setup required to establish > a valid struct page reference is mostly wasted when the only usage in > the block stack is to perform a page_to_pfn() conversion for > dma-mapping. Instances of kmap() / kmap_atomic() usage appear to be > the only occasions in the block stack where struct page is > non-trivially used. A new kmap_atomic_pfn_t() is proposed to handle > those cases. > > Generated with the following semantic patch: > > // bv_page.cocci: convert usage of ->bv_page to use set/get helpers > // usage: make coccicheck COCCI=bv_page.cocci MODE=patch Now that it looks like this patchset can move forward, what do about this one? Run the Coccinelle script late in the merge window to catch all the new bv_page usages targeted for 4.2-rc1? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
