Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1731327 > unrolled thread

Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Minchan Kim <minchan@kernel.org> - 2017-09-13 03:50 +0200
    Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Andrew Morton <akpm@linux-foundation.org> - 2017-09-13 23:10 +0200
      Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead "Huang\, Ying" <ying.huang@intel.com> - 2017-09-14 03:00 +0200
        Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Minchan Kim <minchan@kernel.org> - 2017-09-14 10:20 +0200
      Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Minchan Kim <minchan@kernel.org> - 2017-09-14 10:00 +0200
        Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead "Huang\, Ying" <ying.huang@intel.com> - 2017-09-14 14:10 +0200
          Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Minchan Kim <minchan@kernel.org> - 2017-09-14 15:20 +0200
            Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Andrew Morton <akpm@linux-foundation.org> - 2017-09-14 23:30 +0200
            Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead "Huang\, Ying" <ying.huang@intel.com> - 2017-09-15 05:20 +0200
              Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Minchan Kim <minchan@kernel.org> - 2017-09-15 05:50 +0200
                Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead "Huang\, Ying" <ying.huang@intel.com> - 2017-09-15 06:50 +0200

#1731327 — Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead

On Mon, Aug 07, 2017 at 01:40:36PM +0800, Huang, Ying wrote:
> From: Huang Ying <ying.huang@intel.com>
> 
> The swap readahead is an important mechanism to reduce the swap in
> latency.  Although pure sequential memory access pattern isn't very
> popular for anonymous memory, the space locality is still considered
> valid.
> 
> In the original swap readahead implementation, the consecutive blocks
> in swap device are readahead based on the global space locality
> estimation.  But the consecutive blocks in swap device just reflect
> the order of page reclaiming, don't necessarily reflect the access
> pattern in virtual memory.  And the different tasks in the system may
> have different access patterns, which makes the global space locality
> estimation incorrect.
> 
> In this patch, when page fault occurs, the virtual pages near the
> fault address will be readahead instead of the swap slots near the
> fault swap slot in swap device.  This avoid to readahead the unrelated
> swap slots.  At the same time, the swap readahead is changed to work
> on per-VMA from globally.  So that the different access patterns of
> the different VMAs could be distinguished, and the different readahead
> policy could be applied accordingly.  The original core readahead
> detection and scaling algorithm is reused, because it is an effect
> algorithm to detect the space locality.

Andrew,

Every zram users like low-end android device has used 0 page-cluster
to disable swap readahead because it has no seek cost and works as
synchronous IO operation so if we do readahead multiple pages,
swap falut latency would be (4K * readahead window size). IOW,
readahead is meaningful only if it doesn't bother faulted page's
latency.

However, this patch introduces additional knob /sys/kernel/mm/swap/
vma_ra_max_order as well as page-cluster. It means existing users
has used disabled swap readahead doesn't work until they should be
aware of new knob and modification of their script/code to disable
vma_ra_max_order as well as page-cluster.

I say it's a *regression* and wanted to fix it but Huang's opinion
is that it's not a functional regression so userspace should be fixed
by themselves.
Please look into detail of discussion in
http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E

The discussion is never productive so it's time to follow maintainer's
opinion. Could you share your opinion?

Thanks.

[toc] | [next] | [standalone]

#1731879

On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:

> Every zram users like low-end android device has used 0 page-cluster
> to disable swap readahead because it has no seek cost and works as
> synchronous IO operation so if we do readahead multiple pages,
> swap falut latency would be (4K * readahead window size). IOW,
> readahead is meaningful only if it doesn't bother faulted page's
> latency.
> 
> However, this patch introduces additional knob /sys/kernel/mm/swap/
> vma_ra_max_order as well as page-cluster. It means existing users
> has used disabled swap readahead doesn't work until they should be
> aware of new knob and modification of their script/code to disable
> vma_ra_max_order as well as page-cluster.
> 
> I say it's a *regression* and wanted to fix it but Huang's opinion
> is that it's not a functional regression so userspace should be fixed
> by themselves.
> Please look into detail of discussion in
> http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E

hm, tricky problem.  I do agree that linking the physical and virtual
readahead schemes in the proposed fashion is unfortunate.  I also agree
that breaking existing setups (a bit) is also unfortunate.

Would it help if, when page-cluster is written to zero, we do

printk_once("physical readahead disabled, virtual readahead still
enabled.  Disable virtual readhead via
/sys/kernel/mm/swap/vma_ra_max_order").

Or something like that.  It's pretty lame, but it should help alert the
zram-readahead-disabling people to the issue?

[toc] | [prev] | [next] | [standalone]

#1731998

Hi, Andrew,

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
>
>> Every zram users like low-end android device has used 0 page-cluster
>> to disable swap readahead because it has no seek cost and works as
>> synchronous IO operation so if we do readahead multiple pages,
>> swap falut latency would be (4K * readahead window size). IOW,
>> readahead is meaningful only if it doesn't bother faulted page's
>> latency.
>> 
>> However, this patch introduces additional knob /sys/kernel/mm/swap/
>> vma_ra_max_order as well as page-cluster. It means existing users
>> has used disabled swap readahead doesn't work until they should be
>> aware of new knob and modification of their script/code to disable
>> vma_ra_max_order as well as page-cluster.
>> 
>> I say it's a *regression* and wanted to fix it but Huang's opinion
>> is that it's not a functional regression so userspace should be fixed
>> by themselves.
>> Please look into detail of discussion in
>> http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
>
> hm, tricky problem.  I do agree that linking the physical and virtual
> readahead schemes in the proposed fashion is unfortunate.  I also agree
> that breaking existing setups (a bit) is also unfortunate.
>
> Would it help if, when page-cluster is written to zero, we do
>
> printk_once("physical readahead disabled, virtual readahead still
> enabled.  Disable virtual readhead via
> /sys/kernel/mm/swap/vma_ra_max_order").
>
> Or something like that.  It's pretty lame, but it should help alert the
> zram-readahead-disabling people to the issue?

This sounds good for me.

Hi, Minchan, what do you think about this?  I think for low-end android
device, the end-user may have no opportunity to upgrade to the latest
kernel, the device vendor should care about this.  For desktop users,
the warning proposed by Andrew may help to remind them for the new knob.

Best Regards,
Huang, Ying

[toc] | [prev] | [next] | [standalone]

#1732106

On Thu, Sep 14, 2017 at 08:53:04AM +0800, Huang, Ying wrote:
> Hi, Andrew,
> 
> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
> >
> >> Every zram users like low-end android device has used 0 page-cluster
> >> to disable swap readahead because it has no seek cost and works as
> >> synchronous IO operation so if we do readahead multiple pages,
> >> swap falut latency would be (4K * readahead window size). IOW,
> >> readahead is meaningful only if it doesn't bother faulted page's
> >> latency.
> >> 
> >> However, this patch introduces additional knob /sys/kernel/mm/swap/
> >> vma_ra_max_order as well as page-cluster. It means existing users
> >> has used disabled swap readahead doesn't work until they should be
> >> aware of new knob and modification of their script/code to disable
> >> vma_ra_max_order as well as page-cluster.
> >> 
> >> I say it's a *regression* and wanted to fix it but Huang's opinion
> >> is that it's not a functional regression so userspace should be fixed
> >> by themselves.
> >> Please look into detail of discussion in
> >> http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
> >
> > hm, tricky problem.  I do agree that linking the physical and virtual
> > readahead schemes in the proposed fashion is unfortunate.  I also agree
> > that breaking existing setups (a bit) is also unfortunate.
> >
> > Would it help if, when page-cluster is written to zero, we do
> >
> > printk_once("physical readahead disabled, virtual readahead still
> > enabled.  Disable virtual readhead via
> > /sys/kernel/mm/swap/vma_ra_max_order").
> >
> > Or something like that.  It's pretty lame, but it should help alert the
> > zram-readahead-disabling people to the issue?
> 
> This sounds good for me.
> 
> Hi, Minchan, what do you think about this?  I think for low-end android
> device, the end-user may have no opportunity to upgrade to the latest
> kernel, the device vendor should care about this.  For desktop users,
> the warning proposed by Andrew may help to remind them for the new knob.

Yes, it would be option. At least, we should alert to the user to make
a chance to fix. However, can't we make vma-based readahead new config
option? Please look at the detail in my reply of andrew.

With that, there is no regression with current users and as a bonus,
user can measure both algorithm with their real workload with both
algorithm rather than artificial benchmark. I think recency vs spartial
locality would have each pros and cons so that kind soft landing would
be safer option rather than sudden replacing.
After a while, we can set new algorithm as default.

[toc] | [prev] | [next] | [standalone]

#1732089

On Wed, Sep 13, 2017 at 02:02:29PM -0700, Andrew Morton wrote:
> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
> 
> > Every zram users like low-end android device has used 0 page-cluster
> > to disable swap readahead because it has no seek cost and works as
> > synchronous IO operation so if we do readahead multiple pages,
> > swap falut latency would be (4K * readahead window size). IOW,
> > readahead is meaningful only if it doesn't bother faulted page's
> > latency.
> > 
> > However, this patch introduces additional knob /sys/kernel/mm/swap/
> > vma_ra_max_order as well as page-cluster. It means existing users
> > has used disabled swap readahead doesn't work until they should be
> > aware of new knob and modification of their script/code to disable
> > vma_ra_max_order as well as page-cluster.
> > 
> > I say it's a *regression* and wanted to fix it but Huang's opinion
> > is that it's not a functional regression so userspace should be fixed
> > by themselves.
> > Please look into detail of discussion in
> > http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
> 
> hm, tricky problem.  I do agree that linking the physical and virtual
> readahead schemes in the proposed fashion is unfortunate.  I also agree
> that breaking existing setups (a bit) is also unfortunate.
> 
> Would it help if, when page-cluster is written to zero, we do
> 
> printk_once("physical readahead disabled, virtual readahead still
> enabled.  Disable virtual readhead via
> /sys/kernel/mm/swap/vma_ra_max_order").
> 
> Or something like that.  It's pretty lame, but it should help alert the
> zram-readahead-disabling people to the issue?

It was my last resort. If we cannot find other ways after all, yes, it would
be a minimum we should do. But it still breaks users don't/can't read/modify
alert and program.

How about this?

Can't we make vma-based readahead config option?
With that, users who no interest on readahead don't enable vma-based
readahead. In this case, page-cluster works as expected "disable readahead
completely" so it doesn't break anything.

People who want to use upcoming vma-based readahead can enable the feature
and we can say such unfortunate things in config/document description
somewhere so upcoming users will be aware of that unforunate two knobs.

[toc] | [prev] | [next] | [standalone]

#1732240

Minchan Kim <minchan@kernel.org> writes:

> On Wed, Sep 13, 2017 at 02:02:29PM -0700, Andrew Morton wrote:
>> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
>> 
>> > Every zram users like low-end android device has used 0 page-cluster
>> > to disable swap readahead because it has no seek cost and works as
>> > synchronous IO operation so if we do readahead multiple pages,
>> > swap falut latency would be (4K * readahead window size). IOW,
>> > readahead is meaningful only if it doesn't bother faulted page's
>> > latency.
>> > 
>> > However, this patch introduces additional knob /sys/kernel/mm/swap/
>> > vma_ra_max_order as well as page-cluster. It means existing users
>> > has used disabled swap readahead doesn't work until they should be
>> > aware of new knob and modification of their script/code to disable
>> > vma_ra_max_order as well as page-cluster.
>> > 
>> > I say it's a *regression* and wanted to fix it but Huang's opinion
>> > is that it's not a functional regression so userspace should be fixed
>> > by themselves.
>> > Please look into detail of discussion in
>> > http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
>> 
>> hm, tricky problem.  I do agree that linking the physical and virtual
>> readahead schemes in the proposed fashion is unfortunate.  I also agree
>> that breaking existing setups (a bit) is also unfortunate.
>> 
>> Would it help if, when page-cluster is written to zero, we do
>> 
>> printk_once("physical readahead disabled, virtual readahead still
>> enabled.  Disable virtual readhead via
>> /sys/kernel/mm/swap/vma_ra_max_order").
>> 
>> Or something like that.  It's pretty lame, but it should help alert the
>> zram-readahead-disabling people to the issue?
>
> It was my last resort. If we cannot find other ways after all, yes, it would
> be a minimum we should do. But it still breaks users don't/can't read/modify
> alert and program.
>
> How about this?
>
> Can't we make vma-based readahead config option?
> With that, users who no interest on readahead don't enable vma-based
> readahead. In this case, page-cluster works as expected "disable readahead
> completely" so it doesn't break anything.

Now.  Users can choose between VMA based readahead and original
readahead via a knob as follow at runtime,

/sys/kernel/mm/swap/vma_ra_enabled

Best Regards,
Huang, Ying


> People who want to use upcoming vma-based readahead can enable the feature
> and we can say such unfortunate things in config/document description
> somewhere so upcoming users will be aware of that unforunate two knobs.

[toc] | [prev] | [next] | [standalone]

#1732266

On Thu, Sep 14, 2017 at 08:01:30PM +0800, Huang, Ying wrote:
> Minchan Kim <minchan@kernel.org> writes:
> 
> > On Wed, Sep 13, 2017 at 02:02:29PM -0700, Andrew Morton wrote:
> >> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
> >> 
> >> > Every zram users like low-end android device has used 0 page-cluster
> >> > to disable swap readahead because it has no seek cost and works as
> >> > synchronous IO operation so if we do readahead multiple pages,
> >> > swap falut latency would be (4K * readahead window size). IOW,
> >> > readahead is meaningful only if it doesn't bother faulted page's
> >> > latency.
> >> > 
> >> > However, this patch introduces additional knob /sys/kernel/mm/swap/
> >> > vma_ra_max_order as well as page-cluster. It means existing users
> >> > has used disabled swap readahead doesn't work until they should be
> >> > aware of new knob and modification of their script/code to disable
> >> > vma_ra_max_order as well as page-cluster.
> >> > 
> >> > I say it's a *regression* and wanted to fix it but Huang's opinion
> >> > is that it's not a functional regression so userspace should be fixed
> >> > by themselves.
> >> > Please look into detail of discussion in
> >> > http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
> >> 
> >> hm, tricky problem.  I do agree that linking the physical and virtual
> >> readahead schemes in the proposed fashion is unfortunate.  I also agree
> >> that breaking existing setups (a bit) is also unfortunate.
> >> 
> >> Would it help if, when page-cluster is written to zero, we do
> >> 
> >> printk_once("physical readahead disabled, virtual readahead still
> >> enabled.  Disable virtual readhead via
> >> /sys/kernel/mm/swap/vma_ra_max_order").
> >> 
> >> Or something like that.  It's pretty lame, but it should help alert the
> >> zram-readahead-disabling people to the issue?
> >
> > It was my last resort. If we cannot find other ways after all, yes, it would
> > be a minimum we should do. But it still breaks users don't/can't read/modify
> > alert and program.
> >
> > How about this?
> >
> > Can't we make vma-based readahead config option?
> > With that, users who no interest on readahead don't enable vma-based
> > readahead. In this case, page-cluster works as expected "disable readahead
> > completely" so it doesn't break anything.
> 
> Now.  Users can choose between VMA based readahead and original
> readahead via a knob as follow at runtime,
> 
> /sys/kernel/mm/swap/vma_ra_enabled

It's not a config option and is enabled by default. IOW, it's under the radar
so current users cannot notice it. That's why we want to emit big fat warnning.
when old user set 0 to page-cluster. However, as Andrew said, it's lame.

If we make it config option, product maker/kernel upgrade user can have
a chance to notice and read description so they could be aware of two weird
knobs and help to solve the problem in advance without printk_once warn.
If user has no interest about swap-readahead or skip the new config option
by mistake, it works physcial readahead which means no regression.

>  
> Best Regards,
> Huang, Ying
> 
> 
> > People who want to use upcoming vma-based readahead can enable the feature
> > and we can say such unfortunate things in config/document description
> > somewhere so upcoming users will be aware of that unforunate two knobs.

[toc] | [prev] | [next] | [standalone]

#1732593

On Thu, 14 Sep 2017 22:14:46 +0900 Minchan Kim <minchan@kernel.org> wrote:

> > Now.  Users can choose between VMA based readahead and original
> > readahead via a knob as follow at runtime,
> > 
> > /sys/kernel/mm/swap/vma_ra_enabled
> 
> It's not a config option and is enabled by default. IOW, it's under the radar
> so current users cannot notice it. That's why we want to emit big fat warnning.
> when old user set 0 to page-cluster. However, as Andrew said, it's lame.
> 
> If we make it config option, product maker/kernel upgrade user can have
> a chance to notice and read description so they could be aware of two weird
> knobs and help to solve the problem in advance without printk_once warn.
> If user has no interest about swap-readahead or skip the new config option
> by mistake, it works physcial readahead which means no regression.

Yup, a Kconfig option sounds like a good idea.  And that's a bit more
friendly to tiny kernels as well.

[toc] | [prev] | [next] | [standalone]

#1732695

Minchan Kim <minchan@kernel.org> writes:

> On Thu, Sep 14, 2017 at 08:01:30PM +0800, Huang, Ying wrote:
>> Minchan Kim <minchan@kernel.org> writes:
>> 
>> > On Wed, Sep 13, 2017 at 02:02:29PM -0700, Andrew Morton wrote:
>> >> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
>> >> 
>> >> > Every zram users like low-end android device has used 0 page-cluster
>> >> > to disable swap readahead because it has no seek cost and works as
>> >> > synchronous IO operation so if we do readahead multiple pages,
>> >> > swap falut latency would be (4K * readahead window size). IOW,
>> >> > readahead is meaningful only if it doesn't bother faulted page's
>> >> > latency.
>> >> > 
>> >> > However, this patch introduces additional knob /sys/kernel/mm/swap/
>> >> > vma_ra_max_order as well as page-cluster. It means existing users
>> >> > has used disabled swap readahead doesn't work until they should be
>> >> > aware of new knob and modification of their script/code to disable
>> >> > vma_ra_max_order as well as page-cluster.
>> >> > 
>> >> > I say it's a *regression* and wanted to fix it but Huang's opinion
>> >> > is that it's not a functional regression so userspace should be fixed
>> >> > by themselves.
>> >> > Please look into detail of discussion in
>> >> > http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
>> >> 
>> >> hm, tricky problem.  I do agree that linking the physical and virtual
>> >> readahead schemes in the proposed fashion is unfortunate.  I also agree
>> >> that breaking existing setups (a bit) is also unfortunate.
>> >> 
>> >> Would it help if, when page-cluster is written to zero, we do
>> >> 
>> >> printk_once("physical readahead disabled, virtual readahead still
>> >> enabled.  Disable virtual readhead via
>> >> /sys/kernel/mm/swap/vma_ra_max_order").
>> >> 
>> >> Or something like that.  It's pretty lame, but it should help alert the
>> >> zram-readahead-disabling people to the issue?
>> >
>> > It was my last resort. If we cannot find other ways after all, yes, it would
>> > be a minimum we should do. But it still breaks users don't/can't read/modify
>> > alert and program.
>> >
>> > How about this?
>> >
>> > Can't we make vma-based readahead config option?
>> > With that, users who no interest on readahead don't enable vma-based
>> > readahead. In this case, page-cluster works as expected "disable readahead
>> > completely" so it doesn't break anything.
>> 
>> Now.  Users can choose between VMA based readahead and original
>> readahead via a knob as follow at runtime,
>> 
>> /sys/kernel/mm/swap/vma_ra_enabled
>
> It's not a config option and is enabled by default. IOW, it's under the radar
> so current users cannot notice it. That's why we want to emit big fat warnning.
> when old user set 0 to page-cluster. However, as Andrew said, it's lame.
>
> If we make it config option, product maker/kernel upgrade user can have
> a chance to notice and read description so they could be aware of two weird
> knobs and help to solve the problem in advance without printk_once warn.
> If user has no interest about swap-readahead or skip the new config option
> by mistake, it works physcial readahead which means no regression.

I am OK to make it config option.  But I think VMA based swap readahead
should be enabled by default.  Because per my understanding, default
option should be set for most common desktop users.  And VMA based swap
readahead should benefit them.  People needs to turn off swap readahead
is some special users, the original swap readahead default configuration
isn't for them too.

Best Regards,
Huang, Ying

>>  
>> Best Regards,
>> Huang, Ying
>> 
>> 
>> > People who want to use upcoming vma-based readahead can enable the feature
>> > and we can say such unfortunate things in config/document description
>> > somewhere so upcoming users will be aware of that unforunate two knobs.

[toc] | [prev] | [next] | [standalone]

#1732701

On Fri, Sep 15, 2017 at 11:15:08AM +0800, Huang, Ying wrote:
> Minchan Kim <minchan@kernel.org> writes:
> 
> > On Thu, Sep 14, 2017 at 08:01:30PM +0800, Huang, Ying wrote:
> >> Minchan Kim <minchan@kernel.org> writes:
> >> 
> >> > On Wed, Sep 13, 2017 at 02:02:29PM -0700, Andrew Morton wrote:
> >> >> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
> >> >> 
> >> >> > Every zram users like low-end android device has used 0 page-cluster
> >> >> > to disable swap readahead because it has no seek cost and works as
> >> >> > synchronous IO operation so if we do readahead multiple pages,
> >> >> > swap falut latency would be (4K * readahead window size). IOW,
> >> >> > readahead is meaningful only if it doesn't bother faulted page's
> >> >> > latency.
> >> >> > 
> >> >> > However, this patch introduces additional knob /sys/kernel/mm/swap/
> >> >> > vma_ra_max_order as well as page-cluster. It means existing users
> >> >> > has used disabled swap readahead doesn't work until they should be
> >> >> > aware of new knob and modification of their script/code to disable
> >> >> > vma_ra_max_order as well as page-cluster.
> >> >> > 
> >> >> > I say it's a *regression* and wanted to fix it but Huang's opinion
> >> >> > is that it's not a functional regression so userspace should be fixed
> >> >> > by themselves.
> >> >> > Please look into detail of discussion in
> >> >> > http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
> >> >> 
> >> >> hm, tricky problem.  I do agree that linking the physical and virtual
> >> >> readahead schemes in the proposed fashion is unfortunate.  I also agree
> >> >> that breaking existing setups (a bit) is also unfortunate.
> >> >> 
> >> >> Would it help if, when page-cluster is written to zero, we do
> >> >> 
> >> >> printk_once("physical readahead disabled, virtual readahead still
> >> >> enabled.  Disable virtual readhead via
> >> >> /sys/kernel/mm/swap/vma_ra_max_order").
> >> >> 
> >> >> Or something like that.  It's pretty lame, but it should help alert the
> >> >> zram-readahead-disabling people to the issue?
> >> >
> >> > It was my last resort. If we cannot find other ways after all, yes, it would
> >> > be a minimum we should do. But it still breaks users don't/can't read/modify
> >> > alert and program.
> >> >
> >> > How about this?
> >> >
> >> > Can't we make vma-based readahead config option?
> >> > With that, users who no interest on readahead don't enable vma-based
> >> > readahead. In this case, page-cluster works as expected "disable readahead
> >> > completely" so it doesn't break anything.
> >> 
> >> Now.  Users can choose between VMA based readahead and original
> >> readahead via a knob as follow at runtime,
> >> 
> >> /sys/kernel/mm/swap/vma_ra_enabled
> >
> > It's not a config option and is enabled by default. IOW, it's under the radar
> > so current users cannot notice it. That's why we want to emit big fat warnning.
> > when old user set 0 to page-cluster. However, as Andrew said, it's lame.
> >
> > If we make it config option, product maker/kernel upgrade user can have
> > a chance to notice and read description so they could be aware of two weird
> > knobs and help to solve the problem in advance without printk_once warn.
> > If user has no interest about swap-readahead or skip the new config option
> > by mistake, it works physcial readahead which means no regression.
> 
> I am OK to make it config option.  But I think VMA based swap readahead
> should be enabled by default.  Because per my understanding, default
> option should be set for most common desktop users.  And VMA based swap
> readahead should benefit them.  People needs to turn off swap readahead
> is some special users, the original swap readahead default configuration
> isn't for them too.

Okay. I don't care either one is default if it is a config option.
It still gives a chance to notice a new algorithm so users can decide it
It is absolutely better than silent regressoin and printk tric.
Please add more description about those parallel two readahead algorithms
in somewhere(e.g., vm.txt) so he can understand the situation exactly and
can handle both tunable knobs at the same time.

[toc] | [prev] | [next] | [standalone]

#1732707

Minchan Kim <minchan@kernel.org> writes:

> On Fri, Sep 15, 2017 at 11:15:08AM +0800, Huang, Ying wrote:
>> Minchan Kim <minchan@kernel.org> writes:
>> 
>> > On Thu, Sep 14, 2017 at 08:01:30PM +0800, Huang, Ying wrote:
>> >> Minchan Kim <minchan@kernel.org> writes:
>> >> 
>> >> > On Wed, Sep 13, 2017 at 02:02:29PM -0700, Andrew Morton wrote:
>> >> >> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim <minchan@kernel.org> wrote:
>> >> >> 
>> >> >> > Every zram users like low-end android device has used 0 page-cluster
>> >> >> > to disable swap readahead because it has no seek cost and works as
>> >> >> > synchronous IO operation so if we do readahead multiple pages,
>> >> >> > swap falut latency would be (4K * readahead window size). IOW,
>> >> >> > readahead is meaningful only if it doesn't bother faulted page's
>> >> >> > latency.
>> >> >> > 
>> >> >> > However, this patch introduces additional knob /sys/kernel/mm/swap/
>> >> >> > vma_ra_max_order as well as page-cluster. It means existing users
>> >> >> > has used disabled swap readahead doesn't work until they should be
>> >> >> > aware of new knob and modification of their script/code to disable
>> >> >> > vma_ra_max_order as well as page-cluster.
>> >> >> > 
>> >> >> > I say it's a *regression* and wanted to fix it but Huang's opinion
>> >> >> > is that it's not a functional regression so userspace should be fixed
>> >> >> > by themselves.
>> >> >> > Please look into detail of discussion in
>> >> >> > http://lkml.kernel.org/r/%3C1505183833-4739-4-git-send-email-minchan@kernel.org%3E
>> >> >> 
>> >> >> hm, tricky problem.  I do agree that linking the physical and virtual
>> >> >> readahead schemes in the proposed fashion is unfortunate.  I also agree
>> >> >> that breaking existing setups (a bit) is also unfortunate.
>> >> >> 
>> >> >> Would it help if, when page-cluster is written to zero, we do
>> >> >> 
>> >> >> printk_once("physical readahead disabled, virtual readahead still
>> >> >> enabled.  Disable virtual readhead via
>> >> >> /sys/kernel/mm/swap/vma_ra_max_order").
>> >> >> 
>> >> >> Or something like that.  It's pretty lame, but it should help alert the
>> >> >> zram-readahead-disabling people to the issue?
>> >> >
>> >> > It was my last resort. If we cannot find other ways after all, yes, it would
>> >> > be a minimum we should do. But it still breaks users don't/can't read/modify
>> >> > alert and program.
>> >> >
>> >> > How about this?
>> >> >
>> >> > Can't we make vma-based readahead config option?
>> >> > With that, users who no interest on readahead don't enable vma-based
>> >> > readahead. In this case, page-cluster works as expected "disable readahead
>> >> > completely" so it doesn't break anything.
>> >> 
>> >> Now.  Users can choose between VMA based readahead and original
>> >> readahead via a knob as follow at runtime,
>> >> 
>> >> /sys/kernel/mm/swap/vma_ra_enabled
>> >
>> > It's not a config option and is enabled by default. IOW, it's under the radar
>> > so current users cannot notice it. That's why we want to emit big fat warnning.
>> > when old user set 0 to page-cluster. However, as Andrew said, it's lame.
>> >
>> > If we make it config option, product maker/kernel upgrade user can have
>> > a chance to notice and read description so they could be aware of two weird
>> > knobs and help to solve the problem in advance without printk_once warn.
>> > If user has no interest about swap-readahead or skip the new config option
>> > by mistake, it works physcial readahead which means no regression.
>> 
>> I am OK to make it config option.  But I think VMA based swap readahead
>> should be enabled by default.  Because per my understanding, default
>> option should be set for most common desktop users.  And VMA based swap
>> readahead should benefit them.  People needs to turn off swap readahead
>> is some special users, the original swap readahead default configuration
>> isn't for them too.
>
> Okay. I don't care either one is default if it is a config option.
> It still gives a chance to notice a new algorithm so users can decide it
> It is absolutely better than silent regressoin and printk tric.
> Please add more description about those parallel two readahead algorithms
> in somewhere(e.g., vm.txt) so he can understand the situation exactly and
> can handle both tunable knobs at the same time.

Sure.

Best Regards,
Huang, Ying

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web