| Message ID | 20220315172221.9522-1-bgeffon@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | zram: Add a huge_idle writeback mode | expand |
On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > Today it's only possible to write back as a page, idle, or huge. > A user might want to writeback pages which are huge and idle first > as these idle pages do not require decompression and make a good > first pass for writeback. We're moving towards having many different sizes of page in play, not just PMD and PTE sizes. Is this patch actually a good idea in a case where we have, eg, a 32kB anonymous page on a system with 4kB pages? How should zram handle this case? What's our cut-off for declaring a page to be "huge"?
On Tue, Mar 15, 2022 at 1:28 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > > Today it's only possible to write back as a page, idle, or huge. > > A user might want to writeback pages which are huge and idle first > > as these idle pages do not require decompression and make a good > > first pass for writeback. > > We're moving towards having many different sizes of page in play, > not just PMD and PTE sizes. Is this patch actually a good idea in > a case where we have, eg, a 32kB anonymous page on a system with 4kB > pages? How should zram handle this case? What's our cut-off for > declaring a page to be "huge"? > Huge isn't a great term IMO, but it is what it is. ZRAM_HUGE is used to identify pages which are incompressible. Since zram is a block device which presents PAGE_SIZED blocks, do these new changes which involve many different page sizes matter as that seems orthogonal to the block subsystem. Correct me if I'm misunderstanding. Thanks Brian
On Tue, Mar 15, 2022 at 01:34:21PM -0400, Brian Geffon wrote: > On Tue, Mar 15, 2022 at 1:28 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > > > Today it's only possible to write back as a page, idle, or huge. > > > A user might want to writeback pages which are huge and idle first > > > as these idle pages do not require decompression and make a good > > > first pass for writeback. > > > > We're moving towards having many different sizes of page in play, > > not just PMD and PTE sizes. Is this patch actually a good idea in > > a case where we have, eg, a 32kB anonymous page on a system with 4kB > > pages? How should zram handle this case? What's our cut-off for > > declaring a page to be "huge"? > > > > Huge isn't a great term IMO, but it is what it is. ZRAM_HUGE is used > to identify pages which are incompressible. Since zram is a block > device which presents PAGE_SIZED blocks, do these new changes which > involve many different page sizes matter as that seems orthogonal to > the block subsystem. Correct me if I'm misunderstanding. Oh, so ZRAM's concept of huge is not the same as the "huge" in "hugetlbfs" or "THP"? That's not at all confusing ...
On Tue, Mar 15, 2022 at 1:44 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Tue, Mar 15, 2022 at 01:34:21PM -0400, Brian Geffon wrote: > > On Tue, Mar 15, 2022 at 1:28 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > > > > Today it's only possible to write back as a page, idle, or huge. > > > > A user might want to writeback pages which are huge and idle first > > > > as these idle pages do not require decompression and make a good > > > > first pass for writeback. > > > > > > We're moving towards having many different sizes of page in play, > > > not just PMD and PTE sizes. Is this patch actually a good idea in > > > a case where we have, eg, a 32kB anonymous page on a system with 4kB > > > pages? How should zram handle this case? What's our cut-off for > > > declaring a page to be "huge"? > > > > > > > Huge isn't a great term IMO, but it is what it is. ZRAM_HUGE is used > > to identify pages which are incompressible. Since zram is a block > > device which presents PAGE_SIZED blocks, do these new changes which > > involve many different page sizes matter as that seems orthogonal to > > the block subsystem. Correct me if I'm misunderstanding. > > Oh, so ZRAM's concept of huge is not the same as the "huge" in > "hugetlbfs" or "THP"? That's not at all confusing ... I do not disagree, but there isn't much that can be done about it at this point given the sysfs file takes an argument called "huge"
On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > Today it's only possible to write back as a page, idle, or huge. > A user might want to writeback pages which are huge and idle first > as these idle pages do not require decompression and make a good > first pass for writeback. Hi Brian, I am not sure how much the decompression overhead matter for idle pages writeback since it's already *very slow* path in zram but I agree that it would be a good first pass since the memory saving for huge writing would be cost efficient. Just out of curiosity. Do you have real usecase? > > Signed-off-by: Brian Geffon <bgeffon@google.com> > --- > Documentation/admin-guide/blockdev/zram.rst | 6 ++++++ > drivers/block/zram/zram_drv.c | 10 ++++++---- > 2 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst > index 3e11926a4df9..af1123bfaf92 100644 > --- a/Documentation/admin-guide/blockdev/zram.rst > +++ b/Documentation/admin-guide/blockdev/zram.rst > @@ -343,6 +343,12 @@ Admin can request writeback of those idle pages at right timing via:: > > With the command, zram writeback idle pages from memory to the storage. > > +Additionally, if a user choose to writeback only huge and idle pages > +this can be accomplished with:: > + > + echo huge_idle > /sys/block/zramX/writeback > + > + > If admin want to write a specific page in zram device to backing device, > they could write a page index into the interface. > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index cb253d80d72b..f196902ae554 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -643,8 +643,8 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec, > #define PAGE_WB_SIG "page_index=" > > #define PAGE_WRITEBACK 0 > -#define HUGE_WRITEBACK 1 > -#define IDLE_WRITEBACK 2 > +#define HUGE_WRITEBACK (1<<0) > +#define IDLE_WRITEBACK (1<<1) > > > static ssize_t writeback_store(struct device *dev, > @@ -664,6 +664,8 @@ static ssize_t writeback_store(struct device *dev, > mode = IDLE_WRITEBACK; > else if (sysfs_streq(buf, "huge")) > mode = HUGE_WRITEBACK; > + else if (sysfs_streq(buf, "huge_idle")) > + mode = IDLE_WRITEBACK | HUGE_WRITEBACK; > else { > if (strncmp(buf, PAGE_WB_SIG, sizeof(PAGE_WB_SIG) - 1)) > return -EINVAL; > @@ -725,10 +727,10 @@ static ssize_t writeback_store(struct device *dev, > zram_test_flag(zram, index, ZRAM_UNDER_WB)) > goto next; > > - if (mode == IDLE_WRITEBACK && > + if (mode & IDLE_WRITEBACK && > !zram_test_flag(zram, index, ZRAM_IDLE)) > goto next; > - if (mode == HUGE_WRITEBACK && > + if (mode & HUGE_WRITEBACK && > !zram_test_flag(zram, index, ZRAM_HUGE)) > goto next; > /* > -- > 2.35.1.723.g4982287a31-goog >
On Fri, Mar 18, 2022 at 12:41 PM Minchan Kim <minchan@kernel.org> wrote: > > On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > > Today it's only possible to write back as a page, idle, or huge. > > A user might want to writeback pages which are huge and idle first > > as these idle pages do not require decompression and make a good > > first pass for writeback. > > Hi Brian, > > I am not sure how much the decompression overhead matter for idle pages > writeback since it's already *very slow* path in zram but I agree that > it would be a good first pass since the memory saving for huge writing > would be cost efficient. > > Just out of curiosity. Do you have real usecase? Hi Minchan, Thank you for taking a look. When we are thinking about writeback we're trying to be very sensitive to our devices storage endurance, for this reason we will have a fairly conservative writeback limit. Given that, we want to make sure we're maximizing what lands on disk while still minimizing the refault time. We could take the approach where we always writeback huge pages but then we may result in very quick refaults which would be a huge waste of time. So idle writeback is a must for us and being able to writeback the pages which have maximum value (huge) would be very useful. Brian > > > > > Signed-off-by: Brian Geffon <bgeffon@google.com> > > --- > > Documentation/admin-guide/blockdev/zram.rst | 6 ++++++ > > drivers/block/zram/zram_drv.c | 10 ++++++---- > > 2 files changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst > > index 3e11926a4df9..af1123bfaf92 100644 > > --- a/Documentation/admin-guide/blockdev/zram.rst > > +++ b/Documentation/admin-guide/blockdev/zram.rst > > @@ -343,6 +343,12 @@ Admin can request writeback of those idle pages at right timing via:: > > > > With the command, zram writeback idle pages from memory to the storage. > > > > +Additionally, if a user choose to writeback only huge and idle pages > > +this can be accomplished with:: > > + > > + echo huge_idle > /sys/block/zramX/writeback > > + > > + > > If admin want to write a specific page in zram device to backing device, > > they could write a page index into the interface. > > > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > > index cb253d80d72b..f196902ae554 100644 > > --- a/drivers/block/zram/zram_drv.c > > +++ b/drivers/block/zram/zram_drv.c > > @@ -643,8 +643,8 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec, > > #define PAGE_WB_SIG "page_index=" > > > > #define PAGE_WRITEBACK 0 > > -#define HUGE_WRITEBACK 1 > > -#define IDLE_WRITEBACK 2 > > +#define HUGE_WRITEBACK (1<<0) > > +#define IDLE_WRITEBACK (1<<1) > > > > > > static ssize_t writeback_store(struct device *dev, > > @@ -664,6 +664,8 @@ static ssize_t writeback_store(struct device *dev, > > mode = IDLE_WRITEBACK; > > else if (sysfs_streq(buf, "huge")) > > mode = HUGE_WRITEBACK; > > + else if (sysfs_streq(buf, "huge_idle")) > > + mode = IDLE_WRITEBACK | HUGE_WRITEBACK; > > else { > > if (strncmp(buf, PAGE_WB_SIG, sizeof(PAGE_WB_SIG) - 1)) > > return -EINVAL; > > @@ -725,10 +727,10 @@ static ssize_t writeback_store(struct device *dev, > > zram_test_flag(zram, index, ZRAM_UNDER_WB)) > > goto next; > > > > - if (mode == IDLE_WRITEBACK && > > + if (mode & IDLE_WRITEBACK && > > !zram_test_flag(zram, index, ZRAM_IDLE)) > > goto next; > > - if (mode == HUGE_WRITEBACK && > > + if (mode & HUGE_WRITEBACK && > > !zram_test_flag(zram, index, ZRAM_HUGE)) > > goto next; > > /* > > -- > > 2.35.1.723.g4982287a31-goog > >
On Fri, Mar 18, 2022 at 12:51:14PM -0400, Brian Geffon wrote: > On Fri, Mar 18, 2022 at 12:41 PM Minchan Kim <minchan@kernel.org> wrote: > > > > On Tue, Mar 15, 2022 at 10:22:21AM -0700, Brian Geffon wrote: > > > Today it's only possible to write back as a page, idle, or huge. > > > A user might want to writeback pages which are huge and idle first > > > as these idle pages do not require decompression and make a good > > > first pass for writeback. > > > > Hi Brian, > > > > I am not sure how much the decompression overhead matter for idle pages > > writeback since it's already *very slow* path in zram but I agree that > > it would be a good first pass since the memory saving for huge writing > > would be cost efficient. > > > > Just out of curiosity. Do you have real usecase? > > Hi Minchan, > Thank you for taking a look. When we are thinking about writeback > we're trying to be very sensitive to our devices storage endurance, > for this reason we will have a fairly conservative writeback limit. > Given that, we want to make sure we're maximizing what lands on disk > while still minimizing the refault time. We could take the approach > where we always writeback huge pages but then we may result in very > quick refaults which would be a huge waste of time. So idle writeback > is a must for us and being able to writeback the pages which have > maximum value (huge) would be very useful. Thanks for sharing the thought. It really make sense to me and would be great if it goes on the description.
diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 3e11926a4df9..af1123bfaf92 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -343,6 +343,12 @@ Admin can request writeback of those idle pages at right timing via:: With the command, zram writeback idle pages from memory to the storage. +Additionally, if a user choose to writeback only huge and idle pages +this can be accomplished with:: + + echo huge_idle > /sys/block/zramX/writeback + + If admin want to write a specific page in zram device to backing device, they could write a page index into the interface. diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index cb253d80d72b..f196902ae554 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -643,8 +643,8 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec, #define PAGE_WB_SIG "page_index=" #define PAGE_WRITEBACK 0 -#define HUGE_WRITEBACK 1 -#define IDLE_WRITEBACK 2 +#define HUGE_WRITEBACK (1<<0) +#define IDLE_WRITEBACK (1<<1) static ssize_t writeback_store(struct device *dev, @@ -664,6 +664,8 @@ static ssize_t writeback_store(struct device *dev, mode = IDLE_WRITEBACK; else if (sysfs_streq(buf, "huge")) mode = HUGE_WRITEBACK; + else if (sysfs_streq(buf, "huge_idle")) + mode = IDLE_WRITEBACK | HUGE_WRITEBACK; else { if (strncmp(buf, PAGE_WB_SIG, sizeof(PAGE_WB_SIG) - 1)) return -EINVAL; @@ -725,10 +727,10 @@ static ssize_t writeback_store(struct device *dev, zram_test_flag(zram, index, ZRAM_UNDER_WB)) goto next; - if (mode == IDLE_WRITEBACK && + if (mode & IDLE_WRITEBACK && !zram_test_flag(zram, index, ZRAM_IDLE)) goto next; - if (mode == HUGE_WRITEBACK && + if (mode & HUGE_WRITEBACK && !zram_test_flag(zram, index, ZRAM_HUGE)) goto next; /*
Today it's only possible to write back as a page, idle, or huge. A user might want to writeback pages which are huge and idle first as these idle pages do not require decompression and make a good first pass for writeback. Signed-off-by: Brian Geffon <bgeffon@google.com> --- Documentation/admin-guide/blockdev/zram.rst | 6 ++++++ drivers/block/zram/zram_drv.c | 10 ++++++---- 2 files changed, 12 insertions(+), 4 deletions(-)