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: 10896213 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 8718317E0 for ; Thu, 11 Apr 2019 15:07:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 730442872E for ; Thu, 11 Apr 2019 15:07:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6421028D8A; 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=ham 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 A264E2872E for ; Thu, 11 Apr 2019 15:07:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726667AbfDKPHE (ORCPT ); Thu, 11 Apr 2019 11:07:04 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:44566 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726145AbfDKPHD (ORCPT ); Thu, 11 Apr 2019 11:07:03 -0400 Received: by mail-pl1-f195.google.com with SMTP id g12so3530449pll.11 for ; Thu, 11 Apr 2019 08:07:03 -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=k37K4kHjmop5iDYiU9FAHNKK3ZmaYpXToHjN8l/2oKhG/T6Vwst0WU03xUj2cXqLXn f+cXV3g0W36k/cBt4Y+KvN58zo/yA9cqUfOtEWoMlovnj5zD5wGdAt5iIJTklTBNavGM PbFDiGx1rfleMhLMjLsQumCq8lCvnQZbQB4C21UoieIBGBbESDHcGVEOaK38rlQHb1eu P1ZoLinBJIYOgf6oJ+obAp9rFmpC5DWBMWQ1uqcWhwEA3Nimvi/+w82DEwITYAtI5PVK RENCdhyqjgj/VlZauaB66jH6iLvI4Gr56UjsENbFuJz4PUF3wDlQ3L8WDpgSryNZlhxt Eruw== X-Gm-Message-State: APjAAAXSFHGpwE4+VnCGZlzZPSpLs6uT8UVReDfIn2WmRs3ICk4fLaHW cGUrEfP6k2LNSX0kR09LRjZX7Q== 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-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@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(-)