linux-kernel - Re: boot warnings due to swap: make each swap partition have one address

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] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1302032056550.4662@eggly.anvils>
Date:	Sun, 3 Feb 2013 21:12:05 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Shaohua Li <shli@...nel.org>
cc:	Sasha Levin <sasha.levin@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Shaohua Li <shli@...ionio.com>, Rik van Riel <riel@...hat.com>,
	Minchan Kim <minchan@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: boot warnings due to swap: make each swap partition have one
 address_space

On Wed, 30 Jan 2013, Shaohua Li wrote:
> On Sun, Jan 27, 2013 at 01:40:40PM -0800, Hugh Dickins wrote:
> > 
> > I'm glad Minchan has now pointed you to Rik's posting of two years ago:
> > I think there are more important changes to be made in that direction.
> 
> Not sure how others use multiple swaps, but current lock contention forces us
> to use multiple swaps. I haven't carefully think about Rik's posting, but looks
> it doesn't solve the lock contention problem.

Nobody had reported any swap lock contention problem before your patch,
so no, Rik's posting wasn't directed at that.  I always thought swap
writing patterns a much bigger problem.

But if lock contention there is, then I think it can be implemented
with reducing that in mind.  There are two levels of allocation: one
to allocate the tokens which we will insert in page tables, and one
to allocate the final diskspace to which those tokens will point.

(I may be using totally different language from Rik,
it's the principles that I have in mind, not his actual posting.)

Allocating the tokens can very well be done with per-cpu batches,
perhaps of SWAP_CLUSTER_MAX 32 to match vmscan.c's batching: there
is no significance to their ordering.  And allocating the diskspace
would want to be done in batches, to maximize contiguous writing.

That may not solve all the swap_info_get() contention which you saw,
but should help some.

I'm thinking that we go with your per-swapper-space locking for now;
but I wouldn't mind taking it out again later, if we arrive at a
better solution which benefits even those with a single swap area.

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/