On Thu, May 7, 2015 at 11:40 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * 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. True, that's more "dm-cache" than "RAID accelerator", but point taken. -- 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
