linux-kernel - Re: [PATCH 0/3] readahead drop behind and size adjustment

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]

Date:	Wed, 25 Jul 2007 11:36:48 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Eric St-Laurent <ericstl34@...patico.ca>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Fengguang Wu <fengguang.wu@...il.com>,
	Dave Jones <davej@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	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

Eric St-Laurent wrote:
> On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
> 
>> A new list could be a possibility. One problem with adding lists is just
>> trying to work out how to balance scanning rates between them, another
>> problem is CPU overhead of moving pages from one to another... 
> 
> Disk sizes seem to increase more rapidly that the ability to read them
> quickly.  Fortunately the processing power increase greatly too.
> 
> It may be a good idea to spend more CPU cycles to better decide how the
> VM should juggle with this data. We've got to keep those multi-cores cpu
> busy.

Agreed, up to a level.  You cannot let hundreds of gigabytes
worth of memory sit around with (stale) accessed bits set,
and then have to scan millions of pages all at once when free
memory finally runs low.

The amount of CPU time spent in the pageout code at any point
in time needs to be limited.

> If we don't see much work on this area it's surely because it's really
> not a problem anymore for most workloads. Database have their own cache
> management and disk scheduling, file servers just add more ram or
> processors, etc.

It is a really big problem for some (fairly common) workloads,
though.

One of the main reasons there has been little activity in this
area upstream is that nobody (at least, nobody I talked to)
had real fixes in mind for the problem.

All we had were workarounds for RHEL, not the kind of real
fixes that are interesting for upstream.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
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/