Message ID | alpine.LRH.2.02.2209201350470.26058@file01.intranet.prod.int.rdu2.redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | brd: implement discard | expand |
On Tue, Sep 20, 2022 at 01:52:38PM -0400, Mikulas Patocka wrote: > Hi > > Here I'm sending second version of the brd discard patches. That is quite interesting. btw, something out of topic, I once had some preliminary attempt to add DAX support to brd since brd works as ramdisk and brd-dax could have the following benefits: - DAX can be tested without PMEM devices; - ramdisk fses can be accessed without double page cache; - initrd use cases then can work well without extra page cache and maybe it can perform better than initramfs (without unpack process). I wrote some hack stuff but don't have more time working on it... https://git.kernel.org/pub/scm/linux/kernel/git/xiang/linux.git/log/?h=erofs/initrd-fsdax I'm not sure if others are interested in topic though. It would be helpful to get rid of all brd page->index use cases first. Thanks, Gao Xiang > > Mikulas > -- > dm-devel mailing list > dm-devel@redhat.com > https://listman.redhat.com/mailman/listinfo/dm-devel > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, 21 Sep 2022, Gao Xiang wrote: > On Tue, Sep 20, 2022 at 01:52:38PM -0400, Mikulas Patocka wrote: > > Hi > > > > Here I'm sending second version of the brd discard patches. > > That is quite interesting. > > btw, something out of topic, I once had some preliminary attempt > to add DAX support to brd since brd works as ramdisk and brd-dax > could have the following benefits: > > - DAX can be tested without PMEM devices; > - ramdisk fses can be accessed without double page cache; > - initrd use cases then can work well without extra page cache > and maybe it can perform better than initramfs (without unpack > process). > > I wrote some hack stuff but don't have more time working on it... > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/linux.git/log/?h=erofs/initrd-fsdax > > I'm not sure if others are interested in topic though. > > It would be helpful to get rid of all brd page->index use cases > first. > > Thanks, > Gao Xiang Hi Ramdisk DAX was there in the past, but it was removed in the kernel 4.15. Mikulas -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Sep 27, 2022 at 10:09:04AM -0400, Mikulas Patocka wrote: > > > On Wed, 21 Sep 2022, Gao Xiang wrote: > > > On Tue, Sep 20, 2022 at 01:52:38PM -0400, Mikulas Patocka wrote: > > > Hi > > > > > > Here I'm sending second version of the brd discard patches. > > > > That is quite interesting. > > > > btw, something out of topic, I once had some preliminary attempt > > to add DAX support to brd since brd works as ramdisk and brd-dax > > could have the following benefits: > > > > - DAX can be tested without PMEM devices; > > - ramdisk fses can be accessed without double page cache; > > - initrd use cases then can work well without extra page cache > > and maybe it can perform better than initramfs (without unpack > > process). > > > > I wrote some hack stuff but don't have more time working on it... > > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/linux.git/log/?h=erofs/initrd-fsdax > > > > I'm not sure if others are interested in topic though. > > > > It would be helpful to get rid of all brd page->index use cases > > first. > > > > Thanks, > > Gao Xiang > > Hi > > Ramdisk DAX was there in the past, but it was removed in the kernel 4.15. Hi Mikulas! Thanks for pointing out! I didn't realize that, although I think if we really use brd driver in production, enabling DAX support for brd is much better to remove double caching so that ramdisk can become a real ramdisk for most regular files. I have no idea how other people think about ramdisk DAX, or brd is just a stuff for testing only now. If it behaves like this, sorry about the noise. Thanks, Gao Xiang > > Mikulas -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, 28 Sep 2022, Gao Xiang wrote: > > Hi > > > > Ramdisk DAX was there in the past, but it was removed in the kernel 4.15. > > Hi Mikulas! > > Thanks for pointing out! I didn't realize that, although I think if we really > use brd driver in production, enabling DAX support for brd is much better to > remove double caching so that ramdisk can become a real ramdisk for most > regular files. > > I have no idea how other people think about ramdisk DAX, or brd is just a > stuff for testing only now. If it behaves like this, sorry about the > noise. > > Thanks, > Gao Xiang Hi See the message for the commit 7a862fbbdec665190c5ef298c0c6ec9f3915cf45 for the reason why it was removed. Mikulas -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Thu, Sep 29, 2022 at 04:05:43PM -0400, Mikulas Patocka wrote: > > > On Wed, 28 Sep 2022, Gao Xiang wrote: > > > > Hi > > > > > > Ramdisk DAX was there in the past, but it was removed in the kernel 4.15. > > > > Hi Mikulas! > > > > Thanks for pointing out! I didn't realize that, although I think if we really > > use brd driver in production, enabling DAX support for brd is much better to > > remove double caching so that ramdisk can become a real ramdisk for most > > regular files. > > > > I have no idea how other people think about ramdisk DAX, or brd is just a > > stuff for testing only now. If it behaves like this, sorry about the > > noise. > > > > Thanks, > > Gao Xiang > > Hi > > See the message for the commit 7a862fbbdec665190c5ef298c0c6ec9f3915cf45 > for the reason why it was removed. I've already seen that commit after you told me, yet I think the reasons listed inside are not fundamental reasons why ramdisk cannot support DAX in principle (although I know there are issues as listed to handle.) IMHO, reserving ZONE_DEVICE memory to emulate pmem for ramdisk DAX-like use is inflexible on my side since currently such reserved memory cannot be used for other uses later even the ramdisk actually use little space in practice regardless of its capacity. Thanks, Gao Xiang > > Mikulas -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel