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=-5.5 required=3.0 tests=BAYES_00, 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 DA030C433E4 for ; Mon, 27 Jul 2020 07:58:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A723420672 for ; Mon, 27 Jul 2020 07:58:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A723420672 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2792B6B0003; Mon, 27 Jul 2020 03:58:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 227B36B0007; Mon, 27 Jul 2020 03:58:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13DA36B0008; Mon, 27 Jul 2020 03:58:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id F2A0C6B0003 for ; Mon, 27 Jul 2020 03:58:26 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AD111180AD817 for ; Mon, 27 Jul 2020 07:58:26 +0000 (UTC) X-FDA: 77083103412.21.cord55_3e0e6b126f5f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 86221180442C0 for ; Mon, 27 Jul 2020 07:58:26 +0000 (UTC) X-HE-Tag: cord55_3e0e6b126f5f X-Filterd-Recvd-Size: 2391 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Jul 2020 07:58:25 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 630C468B05; Mon, 27 Jul 2020 09:58:22 +0200 (CEST) Date: Mon, 27 Jul 2020 09:58:22 +0200 From: Christoph Hellwig To: Minchan Kim Cc: Christoph Hellwig , Jens Axboe , Song Liu , Hans de Goede , Richard Weinberger , linux-mtd@lists.infradead.org, dm-devel@redhat.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, drbd-dev@lists.linbit.com, linux-raid@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org Subject: Re: [PATCH 10/14] bdi: remove BDI_CAP_SYNCHRONOUS_IO Message-ID: <20200727075822.GA5355@lst.de> References: <20200726150333.305527-1-hch@lst.de> <20200726150333.305527-11-hch@lst.de> <20200726190639.GA560221@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200726190639.GA560221@google.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 86221180442C0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Jul 26, 2020 at 12:06:39PM -0700, Minchan Kim wrote: > > @@ -528,8 +530,7 @@ static ssize_t backing_dev_store(struct device *dev, > > * freely but in fact, IO is going on so finally could cause > > * use-after-free when the IO is really done. > > */ > > - zram->disk->queue->backing_dev_info->capabilities &= > > - ~BDI_CAP_SYNCHRONOUS_IO; > > + zram->disk->fops = &zram_wb_devops; > > up_write(&zram->init_lock); > > For zram, regardless of BDI_CAP_SYNCHRONOUS_IO, it have used rw_page > every time on read/write path. This one with next patch will make zram > use bio instead of rw_page when it's declared !BDI_CAP_SYNCHRONOUS_IO, > which introduce regression for performance. It really should not matter, as the overhead of setting up a bio is minimal. It also is only used in the legacy mpage buffered I/O code outside of the swap code, which has so many performance issues on its own that even if this made a difference it wouldn't matter. If you want magic treatment for your zram swap code you really need to integrate it with the swap code instead of burding the block layer with all this mess.