lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170912082253.GA2875@bbox>
Date:   Tue, 12 Sep 2017 17:22:53 +0900
From:   Minchan Kim <minchan@...nel.org>
To:     "Huang, Ying" <ying.huang@...el.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, kernel-team <kernel-team@....com>,
        Ilya Dryomov <idryomov@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH 4/5] mm:swap: respect page_cluster for readahead

On Tue, Sep 12, 2017 at 04:07:01PM +0800, Huang, Ying wrote:
< snip >
> >> > My concern is users have been disabled swap readahead by page-cluster would
> >> > be regressed. Please take care of them.
> >> 
> >> How about disable VMA based swap readahead if zram used as swap?  Like
> >> we have done for hard disk?
> >
> > It could be with SWP_SYNCHRONOUS_IO flag which indicates super-fast,
> > no seek cost swap devices if this patchset is merged so VM automatically
> > disables readahead. It is in my TODO but it's orthogonal work.
> >
> > The problem I raised is "Why shouldn't we obey user's decision?",
> > not zram sepcific issue.
> >
> > A user has used SSD as swap devices decided to disable swap readahead
> > by some reason(e.g., small memory system). Anyway, it has worked
> > via page-cluster for a several years but with vma-based swap devices,
> > it doesn't work any more.
> 
> Can they add one more line to their configuration scripts?
> 
> echo 0 > /sys/kernel/mm/swap/vma_ra_max_order

We call it as "regression", don't we?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ