Message ID | 20230221165400.1595247-1-kbusch@meta.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp117412wrd; Tue, 21 Feb 2023 09:02:26 -0800 (PST) X-Google-Smtp-Source: AK7set+k9u+uotWAKSbeW9lF7pMSn0Ya7XNXOaEUJdN9he+3gnn8vsS6GmSS3TlmpVUAx79vG12z X-Received: by 2002:aa7:9e1b:0:b0:5a8:8535:18b with SMTP id y27-20020aa79e1b000000b005a88535018bmr4327456pfq.11.1676998945908; Tue, 21 Feb 2023 09:02:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676998945; cv=none; d=google.com; s=arc-20160816; b=Z4QHPAukT0+PGqukOG8dvhB4tEazh6r0DBaexPQhZk8DBr3ibblfxGcQFkQZFJw/i+ RMc6+8sdT7uDiCHxIepK1Lqm0+KQ/U/vJuuxkhHLHLrjJ3mSsBVAuPtjFh49XKTQNMPf CWUviT1QZQuduM2TKEInHwFghe0bDxBS+Ztq3KL+RDSVjITZqRg8TrkJOa9K6zyvy3Tg YJuHYSRAh5w/pJM2wjbYzzhLmtpjq7arPPy3D1zUWYEL+K/QOpSsmE0gM7VvVKwYj1PU KXlC4HSd6szqm22GZJI+U0wHSd3HVMPX/Wb1jJ6e3gGDq/haDkddDjaAKP8IpqkxWkVQ NMHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Lv9wtK+Nznn45ETj9R3Fhuj6gPKzD5SadJcUnBYgOLQ=; b=TH8fTp/QMvh1fJ1+evFA0upHAdJI7H91TLNWnh2TLUIqNcGY/6pGR7a3hmamO2fFQs ZPPF3Y6ShfahncjuNphjGWAiai4PTiOjWi7huNjtJWezlsAS+6vRhXAmWt/tN6EIJ+Hy bWKeLJ8GvAIX+3sAB3NyMm0Zb9AZg9mZB9fEs0HNKGn+dkduUmCtctbPqgfHZEBdJEjN dikRBU38bf0aqaswAcM+rDS90BYNsj+lsaDCv3sHdXA2v3T+KfF/qai04jaOhToj+G/s 0bli5UE/V4iZrjTtnqwt/8KqDu2v3E7TNESEmU9ZjLmamqg/6MIztAI5krmHZrZqDaIK P6qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@meta.com header.s=s2048-2021-q4 header.b=P0Ku8hmc; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=meta.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q1-20020a056a00084100b0058d9266a507si20128951pfk.376.2023.02.21.09.02.11; Tue, 21 Feb 2023 09:02:25 -0800 (PST) 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; dkim=pass header.i=@meta.com header.s=s2048-2021-q4 header.b=P0Ku8hmc; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=meta.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234702AbjBUQyR (ORCPT <rfc822;hanasaki@gmail.com> + 99 others); Tue, 21 Feb 2023 11:54:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234216AbjBUQyP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Feb 2023 11:54:15 -0500 Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7034B10F6 for <linux-kernel@vger.kernel.org>; Tue, 21 Feb 2023 08:54:14 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31LDjqJD007138 for <linux-kernel@vger.kernel.org>; Tue, 21 Feb 2023 08:54:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=s2048-2021-q4; bh=Lv9wtK+Nznn45ETj9R3Fhuj6gPKzD5SadJcUnBYgOLQ=; b=P0Ku8hmcIFQ1Qij/mJfUcp0QRf/3OcOzbXplOI8L34/kr6qJP8UQBK42btsF1JeovfM1 9UmSK1s6/sLzNce0o4/Ue3SDIbwfXh3zVEPPgq+FUzb2xePVm4Ol0NGkkJnO7bP8E81b kRlWlTnOcUZ+sARg9Nq2X9kJOSjg9/M0sbwxgMsyICxrhfsyZDp725XPqiuG56iGUA6Q 3IUBTnK1jrtnkqHr+UaAReODuNPfeXWWcG74ShAkvPnIQE4QkurJU/ae2isakwUeoOiC rw1XFmRAlZArLhRzs2mgecTepCIwdg+H3CUysNPwNHVRIIBbtVyFlqhJX5E+pyKywrGG cA== Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3nuf8xwnht-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <linux-kernel@vger.kernel.org>; Tue, 21 Feb 2023 08:54:13 -0800 Received: from twshared15216.17.frc2.facebook.com (2620:10d:c0a8:1b::d) by mail.thefacebook.com (2620:10d:c0a8:82::f) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Tue, 21 Feb 2023 08:54:11 -0800 Received: by devbig007.nao1.facebook.com (Postfix, from userid 544533) id D5EF011DFBF75; Tue, 21 Feb 2023 08:54:00 -0800 (PST) From: Keith Busch <kbusch@meta.com> To: Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org> CC: Keith Busch <kbusch@kernel.org>, Bryan O'Donoghue <bryan.odonoghue@linaro.org> Subject: [PATCH] dmapool: push new blocks in ascending order Date: Tue, 21 Feb 2023 08:54:00 -0800 Message-ID: <20230221165400.1595247-1-kbusch@meta.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-FB-Internal: Safe Content-Type: text/plain X-Proofpoint-GUID: JWZacyIf0A60AyEE_VpTanpdoMR3eHeA X-Proofpoint-ORIG-GUID: JWZacyIf0A60AyEE_VpTanpdoMR3eHeA X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-21_09,2023-02-20_02,2023-02-09_01 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758460846864640249?= X-GMAIL-MSGID: =?utf-8?q?1758460846864640249?= |
Series |
dmapool: push new blocks in ascending order
|
|
Commit Message
Keith Busch
Feb. 21, 2023, 4:54 p.m. UTC
From: Keith Busch <kbusch@kernel.org> Some users of the dmapool need their allocations to happen in ascending order. The recent optimizations pushed the blocks in reverse order, so restore the previous behavior by linking the next available block from low-to-high. Fixes: ced6d06a81fb69 ("dmapool: link blocks across pages") Reported-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Keith Busch <kbusch@kernel.org> --- mm/dmapool.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
Comments
On 21/02/2023 16:54, Keith Busch wrote: > From: Keith Busch <kbusch@kernel.org> > > Some users of the dmapool need their allocations to happen in ascending > order. The recent optimizations pushed the blocks in reverse order, so > restore the previous behavior by linking the next available block from > low-to-high. > > Fixes: ced6d06a81fb69 ("dmapool: link blocks across pages") > Reported-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > Signed-off-by: Keith Busch <kbusch@kernel.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
On Tue, Feb 21, 2023 at 08:54:00AM -0800, Keith Busch wrote: > From: Keith Busch <kbusch@kernel.org> > > Some users of the dmapool need their allocations to happen in ascending > order. The recent optimizations pushed the blocks in reverse order, so > restore the previous behavior by linking the next available block from > low-to-high. Who are those users? Also should we document this behavior somewhere so that it isn't accidentally changed again some time in the future?
On Tue, Feb 21, 2023 at 10:02:34AM -0800, Christoph Hellwig wrote: > On Tue, Feb 21, 2023 at 08:54:00AM -0800, Keith Busch wrote: > > From: Keith Busch <kbusch@kernel.org> > > > > Some users of the dmapool need their allocations to happen in ascending > > order. The recent optimizations pushed the blocks in reverse order, so > > restore the previous behavior by linking the next available block from > > low-to-high. > > Who are those users? > > Also should we document this behavior somewhere so that it isn't > accidentally changed again some time in the future? usb/chipidea/udc.c qh_pool called "ci_hw_qh". My initial thought was dmapool isn't the right API if you need a specific order when allocating from it, but I can't readily test any changes to that driver. Restoring the previous behavior is easy enough.
On Tue, 21 Feb 2023 11:07:32 -0700 Keith Busch <kbusch@kernel.org> wrote: > On Tue, Feb 21, 2023 at 10:02:34AM -0800, Christoph Hellwig wrote: > > On Tue, Feb 21, 2023 at 08:54:00AM -0800, Keith Busch wrote: > > > From: Keith Busch <kbusch@kernel.org> > > > > > > Some users of the dmapool need their allocations to happen in ascending > > > order. The recent optimizations pushed the blocks in reverse order, so > > > restore the previous behavior by linking the next available block from > > > low-to-high. > > > > Who are those users? > > > > Also should we document this behavior somewhere so that it isn't > > accidentally changed again some time in the future? > > usb/chipidea/udc.c qh_pool called "ci_hw_qh". It would be helpful to know why these users need this side-effect. Did the drivers break? Or just get slower? Are those drivers misbehaving by assuming this behavior? Should we require that they be altered instead of forever constraining the dmapool implementation in this fashion?
On Thu, Feb 23, 2023 at 12:41:37PM -0800, Andrew Morton wrote: > On Tue, 21 Feb 2023 11:07:32 -0700 Keith Busch <kbusch@kernel.org> wrote: > > > On Tue, Feb 21, 2023 at 10:02:34AM -0800, Christoph Hellwig wrote: > > > On Tue, Feb 21, 2023 at 08:54:00AM -0800, Keith Busch wrote: > > > > From: Keith Busch <kbusch@kernel.org> > > > > > > > > Some users of the dmapool need their allocations to happen in ascending > > > > order. The recent optimizations pushed the blocks in reverse order, so > > > > restore the previous behavior by linking the next available block from > > > > low-to-high. > > > > > > Who are those users? > > > > > > Also should we document this behavior somewhere so that it isn't > > > accidentally changed again some time in the future? > > > > usb/chipidea/udc.c qh_pool called "ci_hw_qh". > > It would be helpful to know why these users need this side-effect. Did > the drivers break? Or just get slower? The affected driver was reported to be unusable without this behavior. > Are those drivers misbehaving by assuming this behavior? Should we I do think they're using the wrong API. You you shouldn't use the dmapool if your blocks need to be arranged in a contiguous address order. They should just directly use dma_alloc_coherent() instead. > require that they be altered instead of forever constraining the dmapool > implementation in this fashion? This change isn't really constraining dmapool where it matters. It's just an unexpected one-time initialization thing. As far as altering those drivers, I'll reach out to someone on that side for comment (I'm currently not familiar with the affected subsystem).
On 24/02/2023 18:24, Keith Busch wrote: > On Thu, Feb 23, 2023 at 12:41:37PM -0800, Andrew Morton wrote: >> On Tue, 21 Feb 2023 11:07:32 -0700 Keith Busch <kbusch@kernel.org> wrote: >> >>> On Tue, Feb 21, 2023 at 10:02:34AM -0800, Christoph Hellwig wrote: >>>> On Tue, Feb 21, 2023 at 08:54:00AM -0800, Keith Busch wrote: >>>>> From: Keith Busch <kbusch@kernel.org> >>>>> >>>>> Some users of the dmapool need their allocations to happen in ascending >>>>> order. The recent optimizations pushed the blocks in reverse order, so >>>>> restore the previous behavior by linking the next available block from >>>>> low-to-high. >>>> >>>> Who are those users? >>>> >>>> Also should we document this behavior somewhere so that it isn't >>>> accidentally changed again some time in the future? >>> >>> usb/chipidea/udc.c qh_pool called "ci_hw_qh". >> >> It would be helpful to know why these users need this side-effect. Did >> the drivers break? Or just get slower? > > The affected driver was reported to be unusable without this behavior. > >> Are those drivers misbehaving by assuming this behavior? Should we > > I do think they're using the wrong API. You you shouldn't use the dmapool if > your blocks need to be arranged in a contiguous address order. They should just > directly use dma_alloc_coherent() instead. > >> require that they be altered instead of forever constraining the dmapool >> implementation in this fashion? > > This change isn't really constraining dmapool where it matters. It's just an > unexpected one-time initialization thing. > > As far as altering those drivers, I'll reach out to someone on that side for > comment (I'm currently not familiar with the affected subsystem). We can always change this driver, I'm fine to do that in-parallel/instead. The symptom we have is a silent failure absent this change so, I just wonder are we really the _only_ code path that would be affected absent the change in this patch ? --- bod
On Tue, 21 Feb 2023 08:54:00 -0800 Keith Busch <kbusch@meta.com> wrote: > Some users of the dmapool need their allocations to happen in ascending > order. The recent optimizations pushed the blocks in reverse order, so > restore the previous behavior by linking the next available block from > low-to-high. As I understand it, this fixes the only known issues with patch series "dmapool enhancements", v4. So we're good for a merge before 6.3-rc1, yes?
On Sat, Feb 25, 2023 at 08:42:39PM -0800, Andrew Morton wrote: > On Tue, 21 Feb 2023 08:54:00 -0800 Keith Busch <kbusch@meta.com> wrote: > > > Some users of the dmapool need their allocations to happen in ascending > > order. The recent optimizations pushed the blocks in reverse order, so > > restore the previous behavior by linking the next available block from > > low-to-high. > > As I understand it, this fixes the only known issues with patch series > "dmapool enhancements", v4. So we're good for a merge before 6.3-rc1, > yes? I was going to say "yes", but Guenter is reporting a new error with the original series. I working on that right now.
On Sat, Feb 25, 2023 at 08:42:39PM -0800, Andrew Morton wrote: > On Tue, 21 Feb 2023 08:54:00 -0800 Keith Busch <kbusch@meta.com> wrote: > > > Some users of the dmapool need their allocations to happen in ascending > > order. The recent optimizations pushed the blocks in reverse order, so > > restore the previous behavior by linking the next available block from > > low-to-high. > > As I understand it, this fixes the only known issues with patch series > "dmapool enhancements", v4. So we're good for a merge before 6.3-rc1, > yes? Okay, I think this is good to go to merge now. My local testing also show this fixes the megaraid issue that Guenter reported on the other thread, so I believe this does indeed fix the only reported issues with the dmapool enhancements. .
On Tue, Feb 21, 2023 at 08:54:00AM -0800, Keith Busch wrote: > From: Keith Busch <kbusch@kernel.org> > > Some users of the dmapool need their allocations to happen in ascending > order. The recent optimizations pushed the blocks in reverse order, so > restore the previous behavior by linking the next available block from > low-to-high. > > Fixes: ced6d06a81fb69 ("dmapool: link blocks across pages") > Reported-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > Signed-off-by: Keith Busch <kbusch@kernel.org> This patch fixes the problem I had observed when trying to boot from the megasas SCSI controller on powernv. Tested-by: Guenter Roeck <linux@roeck-us.net> Thanks, Guenter > --- > mm/dmapool.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/mm/dmapool.c b/mm/dmapool.c > index 1920890ff8d3d..a151a21e571b7 100644 > --- a/mm/dmapool.c > +++ b/mm/dmapool.c > @@ -300,7 +300,7 @@ EXPORT_SYMBOL(dma_pool_create); > static void pool_initialise_page(struct dma_pool *pool, struct dma_page *page) > { > unsigned int next_boundary = pool->boundary, offset = 0; > - struct dma_block *block; > + struct dma_block *block, *first = NULL, *last = NULL; > > pool_init_page(pool, page); > while (offset + pool->size <= pool->allocation) { > @@ -311,11 +311,22 @@ static void pool_initialise_page(struct dma_pool *pool, struct dma_page *page) > } > > block = page->vaddr + offset; > - pool_block_push(pool, block, page->dma + offset); > + block->dma = page->dma + offset; > + block->next_block = NULL; > + > + if (last) > + last->next_block = block; > + else > + first = block; > + last = block; > + > offset += pool->size; > pool->nr_blocks++; > } > > + last->next_block = pool->next_block; > + pool->next_block = first; > + > list_add(&page->page_list, &pool->page_list); > pool->nr_pages++; > } > -- > 2.30.2 > >
diff --git a/mm/dmapool.c b/mm/dmapool.c index 1920890ff8d3d..a151a21e571b7 100644 --- a/mm/dmapool.c +++ b/mm/dmapool.c @@ -300,7 +300,7 @@ EXPORT_SYMBOL(dma_pool_create); static void pool_initialise_page(struct dma_pool *pool, struct dma_page *page) { unsigned int next_boundary = pool->boundary, offset = 0; - struct dma_block *block; + struct dma_block *block, *first = NULL, *last = NULL; pool_init_page(pool, page); while (offset + pool->size <= pool->allocation) { @@ -311,11 +311,22 @@ static void pool_initialise_page(struct dma_pool *pool, struct dma_page *page) } block = page->vaddr + offset; - pool_block_push(pool, block, page->dma + offset); + block->dma = page->dma + offset; + block->next_block = NULL; + + if (last) + last->next_block = block; + else + first = block; + last = block; + offset += pool->size; pool->nr_blocks++; } + last->next_block = pool->next_block; + pool->next_block = first; + list_add(&page->page_list, &pool->page_list); pool->nr_pages++; }