Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp502640imu; Fri, 16 Nov 2018 06:00:18 -0800 (PST) X-Google-Smtp-Source: AJdET5fz6LBUjwv9Q6kVHwuSMBBzo82hetPAT/Abhx3D3rM1/kHg3FM16TBpaU1zjhf9N0Ium4aR X-Received: by 2002:a17:902:1124:: with SMTP id d33-v6mr11375503pla.125.1542376818915; Fri, 16 Nov 2018 06:00:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542376818; cv=none; d=google.com; s=arc-20160816; b=MKbR3+qY0tBHGkrgMU7R5GUlAIP+2lki6pqOWNnn83rtEiCkVC62qOPiqQemggtbHC 8/knXXAwtZs/IBIw3dAdIjaujdKjWtjsDiq+kAG9+2F/sbMquTpY5tllGFs889K9Jv3D WOAZkFA9J7dYwKyspibX2ZagpGdvaXU/8kgleOMNAebsHeCmGf/ebo0cQK1KiRHB+jTz 1w8UBnv3yJNV2jRPznwCNwF4BFQMqW6UnqPZV+r69IZ1F7W54fpGOmShcCNEqtIDQAla PRBRXYcAwdmwi480v/bLe+YjjqdBxG0e4U6k0Vr4N5+IYqMK7eu4OfBPOUclW3tP2q7c AgCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=K5mHLsQTYggCIW/IOKeSmfSZzabXONhltDlRWwrDz+Q=; b=Qd5e0YMFlbiSeuzf8qzxce0WYjOyaMUfvcnnrWfaZ0dyLmklLo0xAhDEPsJ8TJVGh9 v85122geum0mO+O/cTfeYdP3sJr/PHZkGgESqbOm4jGZ45UFCHD23E3R0ulAlGabr1Ky IEgWRTliWupO4YxhpW0+0lAuLyaEFvnQe3TzJAIsdLozR1pk3SldUWwYwBHq9A449Hec xGjLVB1/qIJaoMnpLt+SE3ydyZL1/1RHXsH0syFXKMmFCpRgiZDgyL1B1dz9BZF/V2Rn m7+/y4Ut98p/4Qv9/YB0hjYE1hNDtK4tjokgPi1PCoor969jj6DqHiM9nQ9Td6kIv322 UPPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si3233620pfe.52.2018.11.16.06.00.03; Fri, 16 Nov 2018 06:00:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389875AbeKQAL4 (ORCPT + 99 others); Fri, 16 Nov 2018 19:11:56 -0500 Received: from verein.lst.de ([213.95.11.211]:50117 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727999AbeKQAL4 (ORCPT ); Fri, 16 Nov 2018 19:11:56 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 9EE6068D60; Fri, 16 Nov 2018 14:59:22 +0100 (CET) Date: Fri, 16 Nov 2018 14:59:22 +0100 From: Christoph Hellwig To: Omar Sandoval Cc: Ming Lei , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Kent Overstreet , Mike Snitzer , dm-devel@redhat.com, Alexander Viro , linux-fsdevel@vger.kernel.org, Shaohua Li , linux-raid@vger.kernel.org, linux-erofs@lists.ozlabs.org, David Sterba , linux-btrfs@vger.kernel.org, "Darrick J . Wong" , linux-xfs@vger.kernel.org, Gao Xiang , Christoph Hellwig , Theodore Ts'o , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com Subject: Re: [PATCH V10 18/19] block: kill QUEUE_FLAG_NO_SG_MERGE Message-ID: <20181116135922.GO3165@lst.de> References: <20181115085306.9910-1-ming.lei@redhat.com> <20181115085306.9910-19-ming.lei@redhat.com> <20181116021811.GM23828@vader> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181116021811.GM23828@vader> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 15, 2018 at 06:18:11PM -0800, Omar Sandoval wrote: > This commit message wasn't very clear. Is it the case that > QUEUE_FLAG_NO_SG_MERGE is no longer set by any drivers? I think he wants to say that not doing S/G merging is rather pointless with the current setup of the I/O path, as it isn't going to save you a significant amount of cycles.