Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp467001ybk; Sat, 9 May 2020 08:10:05 -0700 (PDT) X-Google-Smtp-Source: APiQypK4k80MMBIrTQ6xAxQgMCTjeaLS1pxEg9uAjqUzCfSX1i3GzHY7esE25Z6Z3K4MGJ93dQ2d X-Received: by 2002:a17:906:404d:: with SMTP id y13mr6664578ejj.43.1589037005302; Sat, 09 May 2020 08:10:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589037005; cv=none; d=google.com; s=arc-20160816; b=ASGgKgSKY7NMW5Lje8K6V8krxrqkbzMhZlOrlHDLCKdQFi9lY9h2yOf3nKUv0OWUvR xf0QMUEs31ovLojol+bvrFWmaebb1rqtK9omo0WjDilog/8s3IsIFA0rvK2tRmGADzuK wgFeDhyLX+mUMTHmRocecKb43esdUpZa3IdcOwO4fuyBpJD96kEae+qc1MoVU93FdHpB i1C9hprUXDA+yNZh8aubJLrA/bNRUfY+MIhvuN+twpLsAZzG6akmIB94bez0dVB1qoVQ VZXVbpO2c4uOdkUF63O0wfosD+jP67ubLMBM2HlnOfkGhsjbemelKYjU7ypZcIzdg5Cy sAIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=yLn1AXHn00bZ+po9Vb7k6qNSHYdWGkkZ6wxI2pwtGRE=; b=RUvTzb6Flo3CsWQPURPhc4B50IYDRjfSXojlaitrf98Qs0exFAvszLWqcvzpHpbAmo GUWlQ6pHmE+VG0e0nFsxUGVXcWcUQN4w1Urt5IaAc1oVzVMep4S4w/sHkBIyOrs0rQnH CIQfNJTH2KP+prIPytk47LguQHhbZAPYGS/Yrw4TArmmWXQVWkKY1H4g0USBm81+zvg2 sFaWR9VtHF0jD007tKuZXVAQNs0qVBEtdtvSXaLXji/stmRMByuDnQPXN1aj+TsxFkgK fHlXQs0BicdJDM/O7/05QopV9DzRvxHd9WooN1vHw1CX2mORYVBUD8uA3v7U6ASvoGeA yhlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=bCOSwnBB; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id me24si2943208ejb.326.2020.05.09.08.09.28; Sat, 09 May 2020 08:10:05 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=bCOSwnBB; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728179AbgEIPHa (ORCPT + 99 others); Sat, 9 May 2020 11:07:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726782AbgEIPH1 (ORCPT ); Sat, 9 May 2020 11:07:27 -0400 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 402E4C061A0C for ; Sat, 9 May 2020 08:07:27 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id x1so3880549ejd.8 for ; Sat, 09 May 2020 08:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yLn1AXHn00bZ+po9Vb7k6qNSHYdWGkkZ6wxI2pwtGRE=; b=bCOSwnBBjfPXdvYGJ+yVECFvPTePDH1ANyISrMhvJ1qWqJvVThnHr98KsSwJqA14nC yCPOxIRhJYUKs+I0Z7zlDnbc2VJgVwWpDdEA4tIPWEVVkzgs6TyhzHr/LnVPIJc5YbZe /Ga31Bb5nRqdr5sF01D+4kD7nuppvALvlvKumT0LdbEKLra5xfeiNf57Wv0ExKnHb7Rg DbJPWuDEL/VR1p8vve4AZ1c4iNgOcgeDoJddMOToTohvJc+NMCp5pllqs5xHvWVFoT1b hZ2eMoVCvm/W3nphozJEpzuE720t10XyAVjkj8Y23QAnpJ3YgiSQvtyoRGLEW8+4DwBB HlzA== 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=yLn1AXHn00bZ+po9Vb7k6qNSHYdWGkkZ6wxI2pwtGRE=; b=Z0OSq1c5pKt3v72jlyxA4HrwgdJIxpToBEtqsdTQP91bRzUceWHQ4RewdNHslXBH+8 t5XKIUC4wHmjk3eBo6/0MQwfTNIwDiBEcXeY+WhQXz20HwzC33+bWFKIPXnVsxLdKmIO M6fwWZLQR1XomC+mmGL88eyJlRPvu/4B7p23SBUAqgqRMOzhrbLX+lM/J6VNP0M/d1+r R7w2RLgsjwkrm5/A3bm4FTEN0nznvbNevbTP60xe6sQQGh2M1BRtrwfmUw1MBAkGYCdB QcOTgrutqkv30l4Xt3EtLv1932YgakK8vQ/WSATgBhrhC9WykzM7czF64QDdCZgCPJXW h0xQ== X-Gm-Message-State: AGi0PuZ8F/wXQpcfmpE/e8rHlrAKzG6F3K4577SNT54utxk4XGYqR7B+ pVaeAW+iMn8uD80yzyDFRkKtNbstusFjGffVk/6nmQ== X-Received: by 2002:a17:906:855a:: with SMTP id h26mr6685025ejy.56.1589036845508; Sat, 09 May 2020 08:07:25 -0700 (PDT) MIME-Version: 1.0 References: <20200508161517.252308-1-hch@lst.de> <20200509082352.GB21834@lst.de> In-Reply-To: <20200509082352.GB21834@lst.de> From: Dan Williams Date: Sat, 9 May 2020 08:07:14 -0700 Message-ID: Subject: Re: remove a few uses of ->queuedata To: Christoph Hellwig Cc: 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 9, 2020 at 1:24 AM Christoph Hellwig wrote: > > 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. Ah ok. If the changelogs had been filled in with something like "In preparation for removing @q from make_request_fn, stop using ->queuedata", I probably wouldn't have looked twice. For the nvdimm/ driver updates you can add: Reviewed-by: Dan Williams ...or just let me know if you want me to pick those up through the nvdimm tree.