linux-ext4 - Re: [RFC] Parallelize IO for e2fsck

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:	Sat, 26 Jan 2008 00:01:20 +0100 (CET)
From:	Bodo Eggert <7eggert@....de>
To:	Bryan Henderson <hbryan@...ibm.com>
cc:	Theodore Tso <tytso@....EDU>, Bodo Eggert <7eggert@....de>,
	Andreas Dilger <adilger@...sterfs.com>,
	Andreas Dilger <adilger@....com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Adrian Bunk <bunk@...nel.org>, David Chinner <dgc@....com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-linux-kernel@...r.kernel.org, Ric Wheeler <ric@....com>,
	Valerie Henson <val@...consulting.com>, Valdis.Kletnieks@...edu
Subject: Re: [RFC] Parallelize IO for e2fsck

On Fri, 25 Jan 2008, Bryan Henderson wrote:

> > AIX basically did this with SIGDANGER (the signal is ignored by
> > default), except there wasn't the ability for the process to tell the
> > kernel at what level of memory pressure before it should start getting
> > notified, and there was no way for the kernel to tell how bad the
> > memory pressure actually was.  On the other hand, it was a relatively
> > simple design.
> 
> AIX does provide a system call to find out how much paging backing store 
> space is available and the thresholds set by the system administrator. 
> Running out of paging space is the only memory pressure AIX is concerned 
> about.  While I think having processes make memory usage decisions based 
> on that is a shoddy way to manage system resources, that's what it is 
> intended for.

If you start partitioning the system into virtual servers (or something
similar), being close to swapping may be somebody else's problem.
(They shouldn't have exceeded their guaranteed memory limit).


> Incidentally, some context for the AIX approach to the OOM problem: a 
> process may exclude itself from OOM vulnerability altogether.  It places 
> itself in "early allocation" mode, which means at the time it creates 
> virtual memory, it reserves enough backing store for the worst case.  The 
> memory manager does not send such a process the SIGDANGER signal or 
> terminate it when it runs out of paging space.  Before c. 2000, this was 
> the only mode.  Now the default is late allocation mode, which is similar 
> to Linux.

This is an interesting approach. It feels like some programs might be 
interested in choosing this mode instead of risking OOM. 
-- 
The programmer's National Anthem is 'AAAAAAAAHHHHHHHH'
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html