Received: by 2002:ac8:1418:0:b0:3ab:920c:4c8b with SMTP id k24csp3128791qtj; Wed, 18 Jan 2023 13:33:16 -0800 (PST) X-Google-Smtp-Source: AMrXdXsbb5rhHI0tk5TK0deaQyZM+ZmatJxGj10kJ8peg6msB0lHkqtuLKPbeVmHoxQFXW1N86ql X-Received: by 2002:a17:90b:1907:b0:227:1e67:d588 with SMTP id mp7-20020a17090b190700b002271e67d588mr8837542pjb.23.1674077596258; Wed, 18 Jan 2023 13:33:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674077596; cv=none; d=google.com; s=arc-20160816; b=Dn3AbJOM1+tdqnCfuF4spjoho8v9dSENfNDU1rt0nUjb+Lv3kCLpHoo5STd4JuG6/A X7bPB91ondjjW6xcbawCXJxq7GQFxmuf+g7xzXeEgWLG9waewSA4XvZoQ5oYZwlbi4nP C1Weu+6dK5yy2mDJJgav5vzTsWtG/sYl3YeKoYpQHlPQXibmR4/rL7B9loZe5t0E0Zeg NfP+H35i666SwzyQNJraM93EcCaUFs5Sx+fvunu+BZtToiY1AF8H2iI1WMic7wD/GiUz SvCnNj4y/dweiGpTZekBXY1Miqk23qYTeUTgwPxZZkX0FUkfZEvlB0P4bJULSr+573HP WHeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ml4Mq1HxoprduSmaOtE/7qmWaOPc7rT86hVq2mfhQLo=; b=F7EPzRyn3psbf0tuFylgezn+p9HXhpCyEICRJUb2jQ+FnLRoM+/6PN4kO9bCZCLMXm oVDztRqkZG11ExFx2Otvt6vgEDiSpS/+dme0S7zhXPTgkBuVLpK3rKKWFcyX3zCkAU9z aK086UdKLMRHbYhpNALDmF29QCETNbqzdGWco/4hy8z0ThBJJo2zOWrILE3dT8T7lUm3 vorzt1kH3g1JRkCSQ1g5wNIhOaHy8M4KTY8E320g03YHnixtvKA29vLYolGCZHbBclOb Aj2TouqFJWAYFBADpPIYpeTZttrFZLoYH4WVMBy7weti/3AJIxUhOpAPsTEwoF7X1/ck x/VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=PbeDPrXR; 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=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pv7-20020a17090b3c8700b002262f38c314si3101860pjb.120.2023.01.18.13.33.10; Wed, 18 Jan 2023 13:33:16 -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=@google.com header.s=20210112 header.b=PbeDPrXR; 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=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229563AbjARTzW (ORCPT + 45 others); Wed, 18 Jan 2023 14:55:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229482AbjARTzV (ORCPT ); Wed, 18 Jan 2023 14:55:21 -0500 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5AC058983 for ; Wed, 18 Jan 2023 11:55:19 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id 123so6361681ybv.6 for ; Wed, 18 Jan 2023 11:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ml4Mq1HxoprduSmaOtE/7qmWaOPc7rT86hVq2mfhQLo=; b=PbeDPrXRrIm7rSfckMx4+MttBahJf6IY5jVAIjntleKZy4etq34NmHOU6XAyeR+Fab ORwDD6aeT/o+Lzatahvs1Df3hC8Zp4wztM3Tsi7zeoFTDN3ZXTRRATMchdXmd1w6iq9r ULB35+cs0evngWClWp+S7DE9yLcIJr+6DdMZNcBfFC64ZUZ8obBNsKaTSHZoXlg8lZnA wrs0Z7xqGozVMTtQXoGy0Ii+xstY22ORN6Rk8NwXfb9Mdy0EMr8jfUqnhJDwLBzm4CO0 FxiAdjNv/LNw5Q6CHI1oIM4T8Lczsjebkmmr3AaJHUcG3MLFcXdAW7CuWHhXkm5sY8GX boDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ml4Mq1HxoprduSmaOtE/7qmWaOPc7rT86hVq2mfhQLo=; b=Msne5DG0fdDxSDGR/OdfWV0J/Y01u5Yl5dts0hWE1vwfRbjKrL9OVcKR4gtdI/Ovgk jcmlp2WITIERW8Iu+L7CfZSAGTWcu9VokCXYQDk1Uq7GzyZY52DwricRvMaaTfhRV38U nvg9/99OvoJIR1bos/ExHJLDRcHgBy7BLFfhzjvT8+PKkqnQ6LhAPPN6V5inutqe8VcS Zvj0JLqBT3ZNe/nEjBpUQXuTk9eGTrln0o9F8gUsSe3wIfStLTtG1HzaA6rZ0PTcIxKS iGuw58zxev0dwxAoX9+OKFSnh1S+uKR/4meWtL93AX9fHk2TqTuGlvEPg3VVDij8csM6 o9Ag== X-Gm-Message-State: AFqh2kpi3fi2TvLN6PiAgupVbHQq/YgHo3nY0Ki9vqtgy8YWfZxZPRZh jawgds7aBmYgurIK1Z8rOJC51g3eKlZrokAmxsbBpQ== X-Received: by 2002:a25:bd14:0:b0:73f:fb7d:400 with SMTP id f20-20020a25bd14000000b0073ffb7d0400mr1277748ybk.352.1674071718749; Wed, 18 Jan 2023 11:55:18 -0800 (PST) MIME-Version: 1.0 References: <20230117082508.8953-1-jaewon31.kim@samsung.com> <20230117083103epcms1p63382eee1cce1077248a4b634681b0aca@epcms1p6> In-Reply-To: From: "T.J. Mercier" Date: Wed, 18 Jan 2023 11:55:07 -0800 Message-ID: Subject: Re: [PATCH] dma-buf: system_heap: avoid reclaim for order 4 To: John Stultz Cc: jaewon31.kim@samsung.com, "sumit.semwal@linaro.org" , "daniel.vetter@ffwll.ch" , "akpm@linux-foundation.org" , "hannes@cmpxchg.org" , "mhocko@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "jaewon31.kim@gmail.com" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Tue, Jan 17, 2023 at 10:54 PM John Stultz wrote: > > On Tue, Jan 17, 2023 at 12:31 AM Jaewon Kim wrote: > > > Using order 4 pages would be helpful for many IOMMUs, but it could spend > > > quite much time in page allocation perspective. > > > > > > The order 4 allocation with __GFP_RECLAIM may spend much time in > > > reclaim and compation logic. __GFP_NORETRY also may affect. These cause > > > unpredictable delay. > > > > > > To get reasonable allocation speed from dma-buf system heap, use > > > HIGH_ORDER_GFP for order 4 to avoid reclaim. > > Thanks for sharing this! > The case where the allocation gets stuck behind reclaim under pressure > does sound undesirable, but I'd be a bit hesitant to tweak numbers > that have been used for a long while (going back to ion) without a bit > more data. > > It might be good to also better understand the tradeoff of potential > on-going impact to performance from using low order pages when the > buffer is used. Do you have any details like or tests that you could > share to help ensure this won't impact other users? > > TJ: Do you have any additional thoughts on this? > I don't have any data on how often we hit reclaim for mid order allocations. That would be interesting to know. However the 70th percentile of system-wide buffer sizes while running the camera on my phone is still only 1 page, so it looks like this change would affect a subset of use-cases. Wouldn't this change make it less likely to get an order 4 allocation (under memory pressure)? The commit message makes me think the goal of the change is to get more of them. Actually with the low order being 0, I don't think __GFP_COMP makes sense in LOW_ORDER_GFP. But I guess that flag isn't harmful there. > thanks > -john