From patchwork Thu Feb 28 21:36:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 10833751 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C1A93139A for ; Thu, 28 Feb 2019 21:36:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A9E042FBE0 for ; Thu, 28 Feb 2019 21:36:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A5AEE2FBE4; Thu, 28 Feb 2019 21:36:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 612FC2FBD3 for ; Thu, 28 Feb 2019 21:36:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729936AbfB1Vgr (ORCPT ); Thu, 28 Feb 2019 16:36:47 -0500 Received: from mail-it1-f179.google.com ([209.85.166.179]:38948 "EHLO mail-it1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727775AbfB1Vgr (ORCPT ); Thu, 28 Feb 2019 16:36:47 -0500 Received: by mail-it1-f179.google.com with SMTP id l15so18113816iti.4 for ; Thu, 28 Feb 2019 13:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=l8dGsG1FqhROVLj9iqabjaLk2ROz/sFXexoMAbeIzAc=; b=MUI41/U+6UiP2wEuD19dFOD9mX/ZfaEJQl68OgeyOZ5njOuiV6q/wjYpvNPGWKWh0t ybc5DOOZG6K+WwIkaq3gJn5b0I72gkNu2s6tYeVuUiHW3RP96v9dkl+020K6oT74lZOx /Rx70PpmWpxMgyRdFBZ/UjnK2Kdnjpbba+xBkT9wgvIM3Ph6xIxSIpUxcot8P9XQLp0P kgQK9k4BReXirgaRaaNIGdKoPA7zF9cpqTv6iKZsvdmw/ARikDMNlCIYyOAcF86lb8oK w0ADWDlpHKi9hjgRommv6pNYofBM/ZQeFYZsZ8dWzMmOydeSrcpCwz/3SezQECTfJVES 9Ibw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=l8dGsG1FqhROVLj9iqabjaLk2ROz/sFXexoMAbeIzAc=; b=T+SPDU6KYvfq2DOeYw17vAcEcJDh6G985jjmMnunqDo/4/OFJt3VcF0+/Az+X/J5hI N4d7/YG7kss4WjCXovQ8lfVdBOAfFbsgGw8NKJtuDJD2+7W4OlLXKVwHmyEbW+D4CA/F EtK2vbW66zLyI8UCd1jcX/zJjyFrQSo21jjTTE/WBXvAB8iNtbVwx+dhxVe7FGOsuhiU sdoN55oliAfK3S3X8hrN5Oo48OS0StRZR/xYjeZOmnUbEybefhQs1+Bgb2mBPnFQ8MiK xvbKeV1UmOwF6gA55GTRpiQrTiCHfKuU0s2ZW4H1iBlp2TEXvejjwJpeOmjSWvVEei60 q1eg== X-Gm-Message-State: APjAAAU5FQG87Q8b9pf8AI08TFIEHHi6FyleA9PrG8xwKEjdxCge7hIN eYIbThAaVnQ+iTue/rsi/Yza+uj8vgfMoA== X-Google-Smtp-Source: AHgI3IZybekGHFqrBh2t7TCg1tZ079VUQMy2P9/no+mW9dpAfCrAHMc2I/BmWodQgeX1Cbspi4jTJg== X-Received: by 2002:a24:738e:: with SMTP id y136mr1179038itb.147.1551389805870; Thu, 28 Feb 2019 13:36:45 -0800 (PST) Received: from x1.localdomain ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id m79sm1376311itm.25.2019.02.28.13.36.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 13:36:44 -0800 (PST) From: Jens Axboe To: linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org Cc: hch@lst.de, viro@ZenIV.linux.org.uk Subject: [PATCHSET v2 0/2] Re-introduce iov/bio no page referencing Date: Thu, 28 Feb 2019 14:36:40 -0700 Message-Id: <20190228213642.306-1-axboe@kernel.dk> X-Mailer: git-send-email 2.17.1 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The io_uring branch had a patch that enabled us to NOT get/put page references on pages that we have registered from the application. This patch assumed that it was safe to never do this for any ITER_BVEC, but that turned out to be problematic for the splice direct case where we stuff those pages into a pipe and unconditionally release them when the pipe buffer is released. This was fixed by always grabbing an extra page reference before doing IO, and let the caller release that reference. However, this causes a performance regressions since we're now doing an atomic inc/dec per IO needlessly. Instead of assuming that any ITER_BVEC caller knows not to put these page references, have the caller explicitly flag it. This shifts the iter types up a bit, so we can add a bit similar to the read/write bit for managing this information. Patch 2 then re-introduces the BIO_NO_PAGE_REF, which is now limited by both ITER_BVEC _and_ the caller flagged it as safe. Patches are on top of my io_uring branch. Since v1: - Add comment on the bit usages of iter->type - Move ITER_BVEC_FLAG_NO_REF at the start of the enum - Remove superfluous 'const' in iov_iter_bvec_no_ref()