Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp397368imm; Mon, 21 May 2018 07:47:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoW46G5fQgm4hUAIXNjJ+y54YrrGp1G8Jfmc0b5Xa+R1E1xYhYnqPUNcJjNlXtX9EApqba0 X-Received: by 2002:a17:902:680c:: with SMTP id h12-v6mr21168835plk.113.1526914072242; Mon, 21 May 2018 07:47:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526914072; cv=none; d=google.com; s=arc-20160816; b=HrxlUfExx+QTmb3CjWQcy8hmB2CVFsWHQmVeDi54dwYprmWpnFH8wn/tp3YP20GyRc mm03vLS3R09jbxSdINXveBWr+VJf6vTO+MheG4CnVvac2ygr5vXElGfAn0J5SQNeaOKt 0ydEOoxpYk8h/ewFjVTvmsz68UY08UMlBw0lTCzkRlHhFZV7klw4p4WiSoIYsX2hUIVv 1eqTia3fW4EMBLBAZhU6DyFvN/qcy/6Ro+T2rrDnTIH2Rs520UEURDKtILsjPeQh4zGC 35c4f2faAzAHCMgiY95ZfCnYHCFOk5S5akyrYq/BgEXqrZ03C6HDvBokAb0+qFMh8V3y PX1g== 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:arc-authentication-results; bh=6gzxOfNDttds/lkgJ+QwxjXg8xz+kdq7TR7r0jElc70=; b=SjOIW4y3CQ7DPvK/sp2doRzpRwvgtMD763Zw+OUWIsrpbTKF8doxHyEyVOOa8ZOpC9 TWyS1iVTLwsdlda3dufq2vPSxaf38rRMtai6b7iNlikzRrflgugIdkML/wtPzUKVyeLG ryqrjBeY+p5tdrFUt869K5iZZpMs42873Lq+3T6VvboE8ioAWSAsZpsR8b8jevZJXqrA DQknP6h4LfrhptyMPrwUCGnibPH6LLBsdGt6DF7YFErF7CEbFyaf15A9YK2HOUGsIkYX Ebqvm5pEV8xJSSm2kZ5USj2KqQ0yEh5231HCtNZAFmjRPwiAeA0WZLerLO2eUyORuj4T eDfQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n59-v6si14159548plb.198.2018.05.21.07.47.37; Mon, 21 May 2018 07:47:52 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753038AbeEUOrJ (ORCPT + 99 others); Mon, 21 May 2018 10:47:09 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:37178 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752882AbeEUOrF (ORCPT ); Mon, 21 May 2018 10:47:05 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 12BA7C12C4; Mon, 21 May 2018 14:47:04 +0000 (UTC) Received: from localhost (unknown [10.18.25.149]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D00E02166BAD; Mon, 21 May 2018 14:47:03 +0000 (UTC) Date: Mon, 21 May 2018 10:47:03 -0400 From: Mike Snitzer To: Jens Axboe Cc: Kent Overstreet , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, hch@infradead.org, colyli@suse.de, darrick.wong@oracle.com, clm@fb.com, bacik@fb.com, linux-xfs@vger.kernel.org, drbd-dev@lists.linbit.com, linux-btrfs@vger.kernel.org, linux-raid@vger.kernel.org, neilb@suse.com Subject: Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init() Message-ID: <20180521144703.GA19303@redhat.com> References: <20180520222558.7053-1-kent.overstreet@gmail.com> <20180521140348.GA19069@redhat.com> <686d7df6-c7d1-48a6-b7ff-48dc8aff6a62@kernel.dk> <20180521143132.GB19194@redhat.com> <2bbeeb1a-8b99-b06a-eb9b-eb8523c16460@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2bbeeb1a-8b99-b06a-eb9b-eb8523c16460@kernel.dk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 21 May 2018 14:47:04 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 21 May 2018 14:47:04 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'msnitzer@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 21 2018 at 10:36am -0400, Jens Axboe wrote: > On 5/21/18 8:31 AM, Mike Snitzer wrote: > > On Mon, May 21 2018 at 10:19am -0400, > > Jens Axboe wrote: > > > >> On 5/21/18 8:03 AM, Mike Snitzer wrote: > >>> On Sun, May 20 2018 at 6:25pm -0400, > >>> Kent Overstreet wrote: > >>> > >>>> Jens - this series does the rest of the conversions that Christoph wanted, and > >>>> drops bioset_create(). > >>>> > >>>> Only lightly tested, but the changes are pretty mechanical. Based on your > >>>> for-next tree. > >>> > >>> By switching 'mempool_t *' to 'mempool_t' and 'bio_set *' to 'bio_set' > >>> you've altered the alignment of members in data structures. So I'll > >>> need to audit all the data structures you've modified in DM. > >>> > >>> Could we get the backstory on _why_ you're making this change? > >>> Would go a long way to helping me appreciate why this is a good use of > >>> anyone's time. > >> > >> Yeah, it's in the first series, it gets rid of a pointer indirection. > > > > "Allows mempools to be embedded in other structs, getting rid of a > > pointer indirection from allocation fastpaths." > > > > So this is about using contiguous memory or avoiding partial allocation > > failure? Or both? > > > > Or more to it? Just trying to fully appreciate the theory behind the > > perceived associated benefit. > > It's about avoiding a pointer indirection. Instead of having to > follow a pointer to get to that struct, it's simple offset math off > your main structure. > > > I do think the increased risk of these embedded bio_set and mempool_t > > themselves crossing cachelines, or struct members that follow them doing > > so, really detracts from these types of changes. > > Definitely something to look out for, though most of them should be > per-dev structures and not in-flight structures. That makes it a bit > less sensitive. But can't hurt to audit the layouts and adjust if > necessary. This is why it's posted for review :-) This isn't something that is easily caught upfront. Yes we can all be busy little beavers with pahole to audit alignment. But chances are most people won't do it. Reality is there is potential for a regression due to false sharing to creep in if a hot struct member suddenly starts straddling a cacheline. That type of NUMA performance killer is pretty insidious and somewhat tedious to hunt down even when looking for it with specialized tools: https://joemario.github.io/blog/2016/09/01/c2c-blog/