Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3171423pxk; Mon, 21 Sep 2020 07:04:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwb4kUEeotT+PWuRZ4dn8oAfLI6q2y2Ri9Dwu0OraV/SR1zJJIhjuOnmQeFEZAjYVtZlhZC X-Received: by 2002:a05:6402:22fc:: with SMTP id dn28mr50750752edb.365.1600697061200; Mon, 21 Sep 2020 07:04:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600697061; cv=none; d=google.com; s=arc-20160816; b=GSneDmD6nsY0Q8nGvTY09hf7oJ0ivursNoyo94418GU1QUZ4S0SDoTA8xUHEeha0wp Xqrv0RlK0j82eOPhVTSp7ojJh6MMzkCshKbSWqqeJDMoAZgry0EqRHlxnkD0duNzGfmm U6gTS803FARf2ZkDrnNW9a/DCky1rfbahSvPhiHT7rO0FzWWSgVTsf8pw6sR9P1ycBL5 HDjdRSzi80dumPBq4B9ZabyjNfwLdO9RDUQmo41oUBcC0FZzMtiln6OevMSm/dCSavjJ MmE3lUB6OC8tm1rNm7cleT63/czPc6pEO8NP7k4XByjwWEdmepTcQL4Ye8m7inbkDekm HPQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=GTTGCmVSBM6H0JJn+rfc1p4kariWKxxfbPGrWvNKpcY=; b=L3hpSpy7f6aOihS1ntyfXWzKYS0iobwAYt8VbV6IkimT0xqiO9eRKVuW3y1J88LiAL wIjE58mVjA7E8j9dGtCJ7FsPLUTSWZEWanMHMoaXO7IretlEmY17QtOVxlCRNVor1W1e ibPIqo6reGkupAexy2yYaaag8qKV7C9LcscueK7ouijI/lYCcR4cbwMQJULhza/9Ydgb 09Pbbvie8389tLZFi5+m60bSw9bI8C5hxexyWZwwnrK83P/tmeBjVq0I0QDk7elNQ4xc 7YSFDdkl0ODr1Hrj81u4sMrNyzvOwOECg5TjAZnBi3aaNZ1pqPW0tvQmFOe/EK0hiQjj UWQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o23si8231327ejj.533.2020.09.21.07.03.53; Mon, 21 Sep 2020 07:04:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727405AbgIUOAR (ORCPT + 99 others); Mon, 21 Sep 2020 10:00:17 -0400 Received: from verein.lst.de ([213.95.11.211]:40145 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727289AbgIUOAR (ORCPT ); Mon, 21 Sep 2020 10:00:17 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id A75DA68AFE; Mon, 21 Sep 2020 16:00:11 +0200 (CEST) Date: Mon, 21 Sep 2020 16:00:10 +0200 From: Christoph Hellwig To: Coly Li Cc: Christoph Hellwig , Jens Axboe , Song Liu , Hans de Goede , Richard Weinberger , Minchan Kim , Johannes Thumshirn , Justin Sanders , linux-mtd@lists.infradead.org, dm-devel@redhat.com, linux-block@vger.kernel.org, linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org, drbd-dev@lists.linbit.com, linux-raid@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org Subject: Re: [PATCH 03/13] bcache: inherit the optimal I/O size Message-ID: <20200921140010.GA14672@lst.de> References: <20200921080734.452759-1-hch@lst.de> <20200921080734.452759-4-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21, 2020 at 05:54:59PM +0800, Coly Li wrote: > I am not sure whether virtual bcache device's optimal request size can > be simply set like this. > > Most of time inherit backing device's optimal request size is fine, but > there are two exceptions, > - Read request hits on cache device > - User sets sequential_cuttoff as 0, all writing may go into cache > device firstly. > For the above two conditions, all I/Os goes into cache device, using > optimal request size of backing device might be improper. > > Just a guess, is it OK to set the optimal request size of the virtual > bcache device as the least common multiple of cache device's and backing > device's optimal request sizes ? Well, if the optimal I/O size is wrong, the read ahead size also is wrong. Can we just drop the setting?