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: <1185093236.6344.87.camel@localhost.localdomain>
Date:	Sun, 22 Jul 2007 18:33:56 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Fengguang Wu <fengguang.wu@...il.com>
Cc:	Dave Jones <davej@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tim Pepper <lnxninja@...ibm.com>,
	Chris Snook <csnook@...hat.com>
Subject: Re: [PATCH 0/3] readahead drop behind and size adjustment

On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
> - It will avoid large-file-reads-thrashing-my-desktop problem,
>   so most desktop users should like it. But sure there will be counter
>   cases when a user want to keep the data cached.
> - File servers may hurt from it. Imagine a mp3/png file server. The
>   files are large enough to trigger drop-behind, but small (and hot)
>   enough to be cached. Also when a new fedora DVD iso is released, it
>   may be cached for some days. These are only the obvious cases.

I'm still not convinced of the latter case.  If a second user accesses
the file before it pages are thrown out, from my understanding there
won't be readahead but the pages will be put back on the active list
(ie. the dropbehind is undone).

AFAICT this patch truly biasses towards releasing pages from
sequentially accessed files.  So file servers where memory pressure
comes from lots of such files should be fine (bias will work correctly
against least-served files).

The main problem I can see is a low-memory server where we are currently
swapping out pages from non-sequential files (eg. gigantic running java
apps), and now performance might decline because we'll discard file
pages first.

> So I opt for it being made tunable, safe, and turned off by default.

I'd like to see it turned on by default in -mm, and try to come up with
some server-like workload to measure the effect.  Should be easy to
simulate something (eg. apache server, where clients grab some files in
preference, and apache server where clients grab different files).

Peter?

Thanks,
Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ