linux-kernel - Re: speeding up swapoff

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: <Pine.LNX.4.64.0708301132470.26365@blonde.wat.veritas.com>
Date:	Thu, 30 Aug 2007 11:36:36 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Daniel Drake <ddrake@...ntes3d.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: speeding up swapoff

On Thu, 30 Aug 2007, Eric W. Biederman wrote:
> 
> There is one other possibility.  Typically the swap code is using
> compatibility disk I/O functions instead of the best the kernel
> can offer.  I haven't looked recently but it might be worth just
> making certain that there isn't some low-level optimization or
> cleanup possible on that path.  Although I may just be thinking
> of swapfiles.

Andrew rewrote swapfile support in 2.5, making it use FIBMAP at
swapon time: so that in 2.6 swapfiles are as deadlock-free and
as efficient (unless the swapfile happens to be badly fragmented)
as raw disk partitions.

There's certainly scope for a study of I/O patterns in swapping,
it's hard to imagine that improvements couldn't be made (but also
easy to imagine endless disputes over different kinds of workload).
But most people would appreciate an improvement in active swapping,
and not care very much about the swapoff.

Regarding Daniel's use of swapoff: it's a very heavy sledgehammer
for cracking that nut, I strongly agree with those who have pointed
him to mlock and mlockall instead.

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