Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp243720ybk; Sat, 9 May 2020 01:28:09 -0700 (PDT) X-Google-Smtp-Source: APiQypIflFfRh1FUMLXCIyDdR2Ur6+wZONnt5RHFGEiHBwhkN0abcAmDH6mtfQYVKmDXaWPCx0c9 X-Received: by 2002:a17:907:7242:: with SMTP id ds2mr5345694ejc.297.1589012889039; Sat, 09 May 2020 01:28:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589012889; cv=none; d=google.com; s=arc-20160816; b=fKSrucDiC0hnUDRL30/rLvzSckKxvbaVEMNJ7rNAznpIM4WHgvI011GH6bsXX91749 L9iVJXWvCqoI5pAgKpCL+/EaRfm+p+DAlgoKv+qBGKBBtv5FUhCsOSrPeyUZTScq7yJM X5IL8qiMFdh3DVpy6ljfa+zvPdyHW2JDqYBOI7t4UIlED8uzCjowEFQ8pm6mjd1A7YT8 lM951Sf2+IMenyocD32vK/8D7Jj10gx2QOsAo+ShgX6hmcsmTOjRvEDnzF/CJ88ORP5F 5sjMSLzQFp++2tPy9oEI/jJAVG9heoODYN6FujBOMT0if2FmI5+pgSQI38zN0VznJnLk BmgA== 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=f8DmoFqrALtF2vf5AQG27lxcNc49DZLrzakrZzrIo/Y=; b=Iq7eDUmP7J8W+FjBNvstBnWHYp07bDtrawWzfgU8ljNn+kmobcO85x7QukUV9IhgG3 SEn/juMLwpQgqEU/mv1YFvytu34qHcOAuPPfCl51YXDuxLZyJu24q0zRbQbdFzyFxdaY NWzLp6WJtBsokyk80NWevf0S3sA8oYsZ8udRcSGjiw1GdpierU6i4Xt5fqkeKeitFNTJ gvgHaJokF/b1promj8BfVjrG9VIRNEiRVZInehfG1JqwTEq2iWl+rx2cRi34IK0I9B9h kJ/cjWzfR11QObmRAqcdTJHpPfpR/gY6OpfEt5nYiKMzfNpCZKKIOrBHkRZnoQoEFtJf 3OMQ== 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 bu15si2359829edb.129.2020.05.09.01.27.46; Sat, 09 May 2020 01:28:09 -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 S1727887AbgEIIYA (ORCPT + 99 others); Sat, 9 May 2020 04:24:00 -0400 Received: from verein.lst.de ([213.95.11.211]:56114 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727839AbgEIIX6 (ORCPT ); Sat, 9 May 2020 04:23:58 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id DB7F368C7B; Sat, 9 May 2020 10:23:52 +0200 (CEST) Date: Sat, 9 May 2020 10:23:52 +0200 From: Christoph Hellwig To: Dan Williams Cc: Christoph Hellwig , Jens Axboe , Jim Paris , Geoff Levand , Joshua Morris , Philip Kelleher , Minchan Kim , Nitin Gupta , Sergey Senozhatsky , linux-m68k@lists.linux-m68k.org, Linux Kernel Mailing List , linux-xtensa@linux-xtensa.org, drbd-dev@lists.linbit.com, linux-block@vger.kernel.org, linuxppc-dev , linux-bcache@vger.kernel.org, linux-raid , linux-nvdimm Subject: Re: remove a few uses of ->queuedata Message-ID: <20200509082352.GB21834@lst.de> References: <20200508161517.252308-1-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) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 08, 2020 at 11:04:45AM -0700, Dan Williams wrote: > On Fri, May 8, 2020 at 9:16 AM Christoph Hellwig wrote: > > > > Hi all, > > > > various bio based drivers use queue->queuedata despite already having > > set up disk->private_data, which can be used just as easily. This > > series cleans them up to only use a single private data pointer. > > ...but isn't the queue pretty much guaranteed to be cache hot and the > gendisk cache cold? I'm not immediately seeing what else needs the > gendisk in the I/O path. Is there another motivation I'm missing? ->private_data is right next to the ->queue pointer, pat0 and part_tbl which are all used in the I/O submission path (generic_make_request / generic_make_request_checks). This is mostly a prep cleanup patch to also remove the pointless queue argument from ->make_request - then ->queue is an extra dereference and extra churn.