From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A425ECE58F for ; Tue, 15 Oct 2019 14:50:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 351CF214AE for ; Tue, 15 Oct 2019 14:50:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 351CF214AE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A78D08E0007; Tue, 15 Oct 2019 10:50:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A29FD8E0001; Tue, 15 Oct 2019 10:50:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93F5F8E0007; Tue, 15 Oct 2019 10:50:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 724418E0001 for ; Tue, 15 Oct 2019 10:50:36 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id EBEA418026B26 for ; Tue, 15 Oct 2019 14:50:35 +0000 (UTC) X-FDA: 76046305230.06.coil22_5319e2cf6828 X-HE-Tag: coil22_5319e2cf6828 X-Filterd-Recvd-Size: 2698 Received: from gentwo.org (gentwo.org [3.19.106.255]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Oct 2019 14:50:35 +0000 (UTC) Received: by gentwo.org (Postfix, from userid 1002) id EE7CD3F1C2; Tue, 15 Oct 2019 14:50:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id ED97C3E959; Tue, 15 Oct 2019 14:50:34 +0000 (UTC) Date: Tue, 15 Oct 2019 14:50:34 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Hannes Reinecke cc: Matthew Wilcox , Naohiro Aota , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, Andrew Morton Subject: Re: Project idea: Swap to zoned block devices In-Reply-To: Message-ID: References: <20191015043827.160444-1-naohiro.aota@wdc.com> <20191015113548.GD32665@bombadil.infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000115, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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?