* Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > On Thu, May 7, 2015 at 9:18 AM, Christoph Hellwig <hch@xxxxxx> wrote: > > On Wed, May 06, 2015 at 05:19:48PM -0700, Linus Torvalds wrote: > >> What is the primary thing that is driving this need? Do we have a very > >> concrete example? > > > > FYI, I plan to to implement RAID acceleration using nvdimms, and I > > plan to ue pages for that. The code just merge for 4.1 can easily > > support page backing, and I plan to use that for now. This still > > leaves support for the gigantic intel nvdimms discovered over EFI > > out, but given that I don't have access to them, and I dont know > > of any publically available there's little I can do for now. But > > adding on demand allocate struct pages for the seems like the > > easiest way forward. Boaz already has code to allocate pages for > > them, although not on demand but at boot / plug in time. > > Hmmm, the capacities of persistent memory that would be assigned for > a raid accelerator would be limited by diminishing returns. I.e. > there seems to be no point to assign more than 8GB or so to the > cache? [...] Why would that be the case? If it's not a temporary cache but a persistent cache that hosts all the data even after writeback completes then going to huge sizes will bring similar benefits to using a large, fast SSD disk on your desktop... The larger, the better. And it also persists across reboots. It could also host the RAID write intent bitmap (the dirty stripes/chunks bitmap) for extra speedups. (This bitmap is pretty small, but important to speed up resyncs after crashes or power loss.) Thanks, Ingo -- 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
