From patchwork Thu Apr 11 15:06:54 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 10896215 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 05DB11800 for ; Thu, 11 Apr 2019 15:07:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EC24B2872E for ; Thu, 11 Apr 2019 15:07:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DC73228D61; Thu, 11 Apr 2019 15:07:05 +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 881A128D8C for ; Thu, 11 Apr 2019 15:07:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726684AbfDKPHE (ORCPT ); Thu, 11 Apr 2019 11:07:04 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:36215 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726640AbfDKPHE (ORCPT ); Thu, 11 Apr 2019 11:07:04 -0400 Received: by mail-pl1-f196.google.com with SMTP id ck15so3556253plb.3 for ; Thu, 11 Apr 2019 08:07:04 -0700 (PDT) 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=8fFl1KuZoclNUfLG0OkPR+aRz0hGPPyI7B0rMVNLNoU=; b=bF7zOORDDzu2L6/Gk9houVBMS0F+etz1ZRQnZ3oQ7JxCLFhweCnJRh+zabl7QUVFP8 gERr8ctF4S1QrqIW942mlu07Tg2eAIb1gO3IHKWwVtSeD4eheJtQnj08UiAGDFqI+Q03 cKMM1nEtSZWKI3OeAPJfaijBIIzeXB4bnK3Wp5kWiZQFg0bUxp07YppQK1diXYqFI5+D E4OSTH8oPFIf2+5wJKWEd3JqqDlUPJOgD+Dplg36G/sIZeEOUjn4WA+9t3L+ODHO37+R l2rhGYRIgeStqkSOVCLjNj40tsKZjv/V7aGIplRD5ps/Io3kEW7jZr+kiT0Gj6qIq9Y0 bymw== 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=8fFl1KuZoclNUfLG0OkPR+aRz0hGPPyI7B0rMVNLNoU=; b=M0cXjD3/qb1Wwi+JpgY17/Pi45G4P6AjY4ndr5Kfl5T3BleRw1HC0igOblJfWfco6Q uNYsBL72Ep8XrNCK/L90CDchpnANlC4ZJ7KYPiBYF8mc3Yi7SW3gjc+pzWY7bqUZL4Iy vDTJ+qFOkQVU9tw9D6ir8M1Vw9bMEtc0Bq26njAGmy//12pUOdxtPoJ9MYy0O+NcFfNX DpXrCP8iLMU3A7usuRZ6ETe865Ytfzht1+1Yze9kCmgi6KM1XLoUX97WdjLAwPPdjkfr noxthA4gKwMxlpxVSRaJMRNzy4RzqVW+0kNfNxuTBhfBq2dEQI9p5Ey7Zr179L6i83kE GsiQ== X-Gm-Message-State: APjAAAX/jbn+s98F6Qvv3m93Eu/e3oQO4F3iOIqxt5r/m1HmxgVbGBe5 IxXB2txfXWsqPt8cSY933WtIlok7StikSA== X-Google-Smtp-Source: APXvYqzkK2fwA3xttHv+v2T4W2fsvztfyL1CwtxgTdnlJTBhimSgXlYSmigd6E3WbEZ8rbErOTVRug== X-Received: by 2002:a17:902:e407:: with SMTP id ci7mr50459344plb.219.1554995223000; Thu, 11 Apr 2019 08:07:03 -0700 (PDT) Received: from x1.localdomain (66.29.188.166.static.utbb.net. [66.29.188.166]) by smtp.gmail.com with ESMTPSA id s12sm62905062pgc.28.2019.04.11.08.07.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 08:07:01 -0700 (PDT) From: Jens Axboe To: linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org Cc: hch@infradead.org, clm@fb.com Subject: [PATCHSET 0/3] io_uring: add sync_file_range and drains Date: Thu, 11 Apr 2019 09:06:54 -0600 Message-Id: <20190411150657.18480-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 In continuation of the fsync barrier patch from the other day, I reworked that patch to turn it into a general primitive instead. This means that any command can be flagged with IOSQE_IO_DRAIN, which will insert a sequence point in the queue. If a request is marked with IOSQE_IO_DRAIN, then previous commands must complete before this one is issued. Subsequent requests are not started until the drain has completed. The latter is a necessity since we track this through the CQ index. If we allow later commands, then they could complete before earlier commands and we'd mistakenly think that we have satisfied the sequence point. Patch 2 is just a prep patch for patch 3, which adds support for sync_file_range() through io_uring. sync_file_range() is heavily used by RocksDB. Patches are also in my io_uring-next branch; git://git.kernel.dk/linux-block io_uring-next fs/io_uring.c | 142 +++++++++++++++++++++++++++++++++- fs/sync.c | 135 +++++++++++++++++--------------- include/linux/fs.h | 3 + include/uapi/linux/io_uring.h | 3 + 4 files changed, 216 insertions(+), 67 deletions(-)