linux-kernel - Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks

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:	Tue, 21 Aug 2007 15:32:25 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Rik van Riel <riel@...hat.com>
cc:	Peter Zijlstra <peterz@...radead.org>, linux-mm@...ck.org,
	dkegel@...gle.com, akpm@...ux-foundation.org,
	Nick Piggin <npiggin@...e.de>, ak@...e.de,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks

On Tue, 21 Aug 2007, Rik van Riel wrote:

> Christoph Lameter wrote:
> 
> > I want general improvements to reclaim to address the issues that you see
> > and other issues related to reclaim instead of the strange code that makes
> > PF_MEMALLOC allocs compete for allocations from a single slab and putting
> > logic into the kernel to decide which allocs to fail. We can reclaim after
> > all. Its just a matter of finding the right way to do this. 
> 
> The simplest way of achieving that would be to allow
> recursion of the page reclaim code, under the condition
> that the second level call can only reclaim clean pages,
> while the "outer" call does what the VM does today.

Yes that is what the precursor to this patchset does.

See http://marc.info/?l=linux-mm&m=118710207203449&w=2

This one did not even come up to the level of the earlier one. Sigh.

The way forward may be:

1. Like in the earlier patchset allow reentry to reclaim under 
   PF_MEMALLOC if we are out of all memory.

2. Do the laundry as here but do not write out laundry directly.
   Instead move laundry to a new lru style list in the zone structure.
   This will allow the recursive reclaim to also trigger writeout
   of pages (what this patchset was supposed to accomplish).

3. Perform writeback only from kswapd. Make other threads
   wait on kswapd if memory is low, we can wait and writeback still
   has to progress.

4. Then allow reclaim of GFP_ATOMIC allocs (see
   http://marc.info/?l=linux-kernel&m=118710595617696&w=2). Atomic
   reclaim can then also put pages onto the zone laundry lists from where
   it is going to be picked up and written out by kswapd ASAP. This one
   may be tricky so maybe keep this separate.

-
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/