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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 7A45CC4360F for ; Mon, 25 Mar 2019 18:44:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4FA0020700 for ; Mon, 25 Mar 2019 18:44:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TdjNsVdq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729938AbfCYSoN (ORCPT ); Mon, 25 Mar 2019 14:44:13 -0400 Received: from mail-yw1-f47.google.com ([209.85.161.47]:42940 "EHLO mail-yw1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729322AbfCYSoN (ORCPT ); Mon, 25 Mar 2019 14:44:13 -0400 Received: by mail-yw1-f47.google.com with SMTP id e76so7828296ywa.9; Mon, 25 Mar 2019 11:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xYljHFR5S3LW6Ou7Zjp0c63LdxqcV6xKlfpZzH3Q45M=; b=TdjNsVdqiPyK3h1K++ttzMS+zeQGQCe8ETeslVL7jvZfokjnRhevNulAK6KnnfaYG/ YwzmZzkbyxEdo7jpt0/22EGPzmwYaNMufewtjTL2zgppzSCDEAXJBJ0m242/RknobTOh FH2cY+aXaKUcSGPTjuT4E2FV9b0+k1bN+F3lx8xiZuLZrFRLCPfG9SRuj+Ebjn9f1G+n MZJ7NIWrmKgWVq677MmxIvNvlIJZXO3lGZrCAOZFRY3ScGk5/rr816IL7Wj1HX4cWcuJ ++KK5uAsz1dIf1Qe81krNYtdl4FDj2A8GtkOUlyIAOs+dNRkeu9DSXnzhaXL34llint3 qUHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xYljHFR5S3LW6Ou7Zjp0c63LdxqcV6xKlfpZzH3Q45M=; b=kt005JcIk/da60OnT3YNoavffS1BIn4Xjx8ZWg92HG9wNSnycPcMWYBNX/nCFm9MJV CtJSXH4G9FfTltL3LGdzgoEplc760eyXeOqAtLeVudg6EdejlF6p5FpPDQQitdbplxtF 2o3zfQOXXZkqyG38WcWXJow1F4Oarv8Bovx0Wu7ZK+cEJFnN9WcMYelA8oOAjmlHgqRn P7g8vFOHrhiBu0KMZ0ungth6d1yoJRf/iHD2E0QWo1Z6jX69VDlcNUJXFB50IF2wJxS/ 6p7LORvFQy8rsdeKDOFIK4I5aO5WjKpsgEYN58x8+llr1QAU+6kn99b6e2xtHEx9Pmu8 6moQ== X-Gm-Message-State: APjAAAU8XLZ45C7fPVMDNHb6aQnV8x0xtUavMpDow+4Z2V5W5ilDre1+ fOa584t29opMm6k5vBbx38OpojRixFzzrhKOjwU= X-Google-Smtp-Source: APXvYqzL+4TbRhvpfn1at+0V6hes3h44GzI7n2XQZKws/Hu+2b1+sf/QhXo+E0oOHk7nSa/Ypm/bsWg+Ldx9leZHY2E= X-Received: by 2002:a0d:e252:: with SMTP id l79mr21807375ywe.248.1553539452181; Mon, 25 Mar 2019 11:44:12 -0700 (PDT) MIME-Version: 1.0 References: <20190325001044.GA23020@dastard> <20190325154731.GT1183@magnolia> <20190325180213.GA31766@lst.de> In-Reply-To: <20190325180213.GA31766@lst.de> From: Amir Goldstein Date: Mon, 25 Mar 2019 20:44:01 +0200 Message-ID: Subject: Re: [QUESTION] Long read latencies on mixed rw buffered IO To: Christoph Hellwig Cc: "Darrick J. Wong" , Dave Chinner , linux-xfs , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Mar 25, 2019 at 8:02 PM Christoph Hellwig wrote: > > On Mon, Mar 25, 2019 at 07:56:33PM +0200, Amir Goldstein wrote: > > Sure, let's give that a shot. But allow me to stay skeptical, because > > I don't think there is a one-size-fits-all solution. > > If application doesn't need >4K atomicity and xfs imposes file-wide > > read locks, there is bound to exist a workload where ext4 can guaranty > > lower latencies than xfs. > > > > Then again, if we fix rw_semaphore to do a good enough job for my > > workload, I may not care about those worst case workloads... > > Downgrading these long standing guarantees is simply not an option. Right. Not without user opt-in. > > Not quite sure what the I/O pattern of your workload is, but if it > is reads from other regions than you write to you should look into > implementing range locks. Workload is a VM image file (VDI) accessed with random IO pattern over SMB. I am still studying the accurate rd/wr mix patterns that really matter to customers. Thanks, Amir.