Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp5701807iob; Tue, 10 May 2022 01:24:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRvke/6jIIoPsMn0rmqvB0F2KHikZyUVfqxy6Ptd6ixUvV0IRJF9OUf28+azbmjly52b+z X-Received: by 2002:aa7:cd58:0:b0:427:b21f:5f79 with SMTP id v24-20020aa7cd58000000b00427b21f5f79mr21650000edw.172.1652171047206; Tue, 10 May 2022 01:24:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652171047; cv=none; d=google.com; s=arc-20160816; b=PJOSnyZRn5fGYMGBR+dyb8bx9jACxkh1Dx4tV9wWhIFD9vQxZmdDDBP4ugAC+yBA0r bHw40CDznQ9sjLubkwyADVEweXsrW/AfS0zTyDekMQv8AEa3LLhI6vg8YyQ/8yUfx2Fu Ak37QukQxOFRm6fMaYsihIhsehWI58CqCavgycVmm4Xzq3wGFbhpBVs/xCCb90CcaVFm PMwlGgLe/LisR1eKcZxLmuo7SMB+l3GnVSh/fPbd2BRDntjrS7yrGq7lgsX2iJNl5f6C c3kS/oOV1GAIqge2O9dfE48iCYFiqeFl755Iw5CeKmsKvyAa3mB4L/bp1A2ffCCIpUTq nMcQ== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3nF8Vv5UiEVhFaFwLplL0T+3RDDK+uyS8iI4cMHdqOw=; b=P5WGXw9IxzAdwYhTZcQF4Yb71H71iObcWVSl7ScpeSmIx9lqk5WKL6f6phD61pywQO BYh5jMuMqygux3kCvV2K4TAyJ+DPzYWb+bLlKgq/HE+FuTTli3ZUxKj6Iu7rPqTVkm5h 8wxvGyctULGg50QJgsbEkp0X0/uriH7MunV7av+CrsbDx+B/0hTPG5lNcYUCSSwENZ1M T9R8Z7hKwVX6GE7FQ3J96AqYIZ2qvF4CpWs19xyrEU8xYUY3Yg7zLcL5K7LjKy//eV6J FP3rYcewFy56P4SVgxdEFHRHD0IB0joXEdp9kULsjuPD6hesbHsN0xqa7j7kDTp3csU2 zQbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d21-20020a170906305500b006e0f9bb2596si15065323ejd.925.2022.05.10.01.23.42; Tue, 10 May 2022 01:24:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237628AbiEJHfn (ORCPT + 99 others); Tue, 10 May 2022 03:35:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238509AbiEJHH5 (ORCPT ); Tue, 10 May 2022 03:07:57 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 951211D8135 for ; Tue, 10 May 2022 00:04:00 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id B31E468AFE; Tue, 10 May 2022 09:03:56 +0200 (CEST) Date: Tue, 10 May 2022 09:03:56 +0200 From: Christoph Hellwig To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Christoph Hellwig , Keith Busch , Jens Axboe , Sagi Grimberg , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [PATCH] nvme-pci: fix host memory buffer allocation size Message-ID: <20220510070356.GA11660@lst.de> References: <20220428101922.14216-1-linux@weissschuh.net> <20220428143603.GA20460@lst.de> <5060d75e-46c0-4d29-a334-62c7e9714fa7@t-8ch.de> <20220428150644.GA22685@lst.de> <676c02ef-4bbc-43f3-b3e6-27a7d353f974@t-8ch.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <676c02ef-4bbc-43f3-b3e6-27a7d353f974@t-8ch.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 28, 2022 at 06:09:11PM +0200, Thomas Weißschuh wrote: > > > On my hardware we start with a chunk_size of 4MiB and just allocate > > > 8 (hmmaxd) * 4 = 32 MiB which is worse than 1 * 200MiB. > > > > And that is because the hardware only has a limited set of descriptors. > > Wouldn't it make more sense then to allocate as much memory as possible for > each descriptor that is available? > > The comment in nvme_alloc_host_mem() tries to "start big". > But it actually starts with at most 4MiB. Compared to what other operating systems offer, that is quite large. > And on devices that have hmminds > 4MiB the loop condition will never succeed > at all and HMB will not be used. > My fairly boring hardware already is at a hmminds of 3.3MiB. > > > Is there any real problem you are fixing with this? Do you actually > > see a performance difference on a relevant workload? > > I don't have a concrete problem or performance issue. > During some debugging I stumbled in my kernel logs upon > "nvme nvme0: allocated 32 MiB host memory buffer" > and investigated why it was so low. Until recently we could not even support these large sizes at all on typical x86 configs. With my fairly recent change to allow vmap remapped iommu allocations on x86 we can do that now. But if we unconditionally enabled it I'd be a little worried about using too much memory very easily. We could look into removing the min with PAGE_SIZE * MAX_ORDER_NR_PAGES to try to do larger segments for "segment challenged" controllers now that it could work on a lot of iommu enabled setups. But I'd rather have a very good reason for that.