linux-kernel - Re: [PATCH -mm] throttle direct reclaim when too many pages are isolated already (v3)

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:	Thu, 16 Jul 2009 00:09:05 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Wu Fengguang <fengguang.wu@...el.com>
Subject: Re: [PATCH -mm] throttle direct reclaim when too many pages are isolated
 already (v3)

Andrew Morton wrote:

> While I agree that handling fatal signals on the direct reclaim path
> is probably a good thing, this seems like a fairly random place at
> which to start the enhancement.

You are right, the direct reclaim path has one other
place where congestion_wait is called in a loop,
do_try_to_free_pages itself - we'll probably want to
break out of that loop too, if the task is about to
die and free all its memory.

> If we were to step back and approach this in a broader fashion, perhaps
> we would find some commonality with the existing TIF_MEMDIE handling,
> dunno.

Good point - what is it that makes TIF_MEMDIE special
wrt. other fatal signals, anyway?

I wonder if we should not simply "help along" any task
with fatal signals pending, anywhere in the VM (and maybe
other places in the kernel, too).

The faster we get rid of a killed process, the sooner its
resources become available to the other processes.

> And I question the testedness of v3 :)

No question about that :)

-- 
All rights reversed.
--
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/