From: Christopher Lameter <cl@linux.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Matthew Wilcox <willy@infradead.org>,
Naohiro Aota <naohiro.aota@wdc.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-block@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Project idea: Swap to zoned block devices
Date: Tue, 15 Oct 2019 14:50:34 +0000 (UTC) [thread overview]
Message-ID: <alpine.DEB.2.21.1910151449170.2977@www.lameter.com> (raw)
In-Reply-To: <d9919d4e-4487-c0e5-c483-cebb5b8a4fc8@suse.de>
On Tue, 15 Oct 2019, Hannes Reinecke wrote:
> On 10/15/19 1:35 PM, Matthew Wilcox wrote:
> > On Tue, Oct 15, 2019 at 01:38:27PM +0900, Naohiro Aota wrote:
> >> A zoned block device consists of a number of zones. Zones are
> >> either conventional and accepting random writes or sequential and
> >> requiring that writes be issued in LBA order from each zone write
> >> pointer position. For the write restriction, zoned block devices are
> >> not suitable for a swap device. Disallow swapon on them.
> >
> > That's unfortunate. I wonder what it would take to make the swap code be
> > suitable for zoned devices. It might even perform better on conventional
> > drives since swapout would be a large linear write. Swapin would be a
> > fragmented, seeky set of reads, but this would seem like an excellent
> > university project.
> >
> The main problem I'm seeing is the eviction of pages from swap.
> While swapin is easy (as you can do random access on reads), evict pages
> from cache becomes extremely tricky as you can only delete entire zones.
> So how to we mark pages within zones as being stale?
> Or can we modify the swapin code to always swap in an entire zone and
> discard it immediately?
On swapout you would change the block number on the swap device to the
latest and increment it?
Mark the prio block number as unused and then at some convenient time scan
the map and see if you can somehow free up a zone?
next prev parent reply other threads:[~2019-10-15 14:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 4:38 [PATCH] mm, swap: disallow swapon() on zoned block devices Naohiro Aota
2019-10-15 7:57 ` Christoph Hellwig
2019-10-15 8:58 ` [PATCH v2] " Naohiro Aota
2019-10-15 9:06 ` Christoph Hellwig
2019-10-15 20:43 ` Andrew Morton
2019-10-15 11:35 ` Project idea: Swap to " Matthew Wilcox
2019-10-15 13:27 ` Theodore Y. Ts'o
2019-10-15 13:48 ` Hannes Reinecke
2019-10-15 14:50 ` Christopher Lameter [this message]
2019-10-15 15:09 ` Matthew Wilcox
2019-10-15 15:22 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1910151449170.2977@www.lameter.com \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=hare@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=naohiro.aota@wdc.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).