linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Minchan Kim <minchan@kernel.org>, "Huang\,
	Ying" <ying.huang@intel.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Rik van Riel" <riel@redhat.com>, Shaohua Li <shli@kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Fengguang Wu <fengguang.wu@intel.com>,
	Tim Chen <tim.c.chen@intel.com>,
	Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead
Date: Thu, 14 Sep 2017 08:53:04 +0800	[thread overview]
Message-ID: <87lglim77z.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20170913140229.8a6cad6f017fa3ea8b53cefc@linux-foundation.org> (Andrew Morton's message of "Wed, 13 Sep 2017 14:02:29 -0700")

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

  reply	other threads:[~2017-09-14  0:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07  5:40 [PATCH -mm -v4 0/5] mm, swap: VMA based swap readahead Huang, Ying
2017-08-07  5:40 ` [PATCH -mm -v4 1/5] mm, swap: Add swap readahead hit statistics Huang, Ying
2017-08-09 21:50   ` Andrew Morton
2017-08-09 23:17     ` Huang, Ying
2017-08-07  5:40 ` [PATCH -mm -v4 2/5] mm, swap: Fix swap readahead marking Huang, Ying
2017-08-07  5:40 ` [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead Huang, Ying
2017-09-13  1:40   ` Minchan Kim
2017-09-13 21:02     ` Andrew Morton
2017-09-14  0:53       ` Huang, Ying [this message]
2017-09-14  8:15         ` Minchan Kim
2017-09-14  7:53       ` Minchan Kim
2017-09-14 12:01         ` Huang, Ying
2017-09-14 13:14           ` Minchan Kim
2017-09-14 21:21             ` Andrew Morton
2017-09-15  3:15             ` Huang, Ying
2017-09-15  3:42               ` Minchan Kim
2017-09-15  4:46                 ` Huang, Ying
2017-08-07  5:40 ` [PATCH -mm -v4 4/5] mm, swap: Add sysfs interface for " Huang, Ying
2017-08-07  5:40 ` [PATCH -mm -v4 5/5] mm, swap: Don't use VMA based swap readahead if HDD is used as swap Huang, Ying

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lglim77z.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=fengguang.wu@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=shli@kernel.org \
    --cc=tim.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).