From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23EB6C32793 for ; Wed, 18 Jan 2023 19:55:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 979E66B0074; Wed, 18 Jan 2023 14:55:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 929186B0075; Wed, 18 Jan 2023 14:55:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F0806B0078; Wed, 18 Jan 2023 14:55:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 701596B0074 for ; Wed, 18 Jan 2023 14:55:21 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 41E7E808BE for ; Wed, 18 Jan 2023 19:55:21 +0000 (UTC) X-FDA: 80368974042.21.E53333B Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf25.hostedemail.com (Postfix) with ESMTP id B3569A0003 for ; Wed, 18 Jan 2023 19:55:19 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=PbeDPrXR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674071719; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ml4Mq1HxoprduSmaOtE/7qmWaOPc7rT86hVq2mfhQLo=; b=piJFpT8nI2pH9f4y6n8l/r9SbTxNp+kYHdUj4/8Wg6tvNyNM0KMxpkx+JGjT8+rgQZbnrS 1IuEsucqXMMWHoHH8aCZHOeFT0/J99jqWOcjm9+6ybWj0BmDtDJdsrV+TPX9F2m/cn32Ge tpshH6+3I4slqP3M9+pMJQzF6Q9ZD64= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=PbeDPrXR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674071719; a=rsa-sha256; cv=none; b=dK5p6s02R5/q/cRYT12ljN+4J29lBphWPz1ycErIBw6UKJWMDAmbmlW8BF2/jfbSCfYaPE /a8F4e1XGi3L+GBg6nqLZT/fj4GdWSK9HN86fmGoOcVCQlNTA/iBYz4cd6l/ZZLmHHk5Yn j1iur9kH08jxpCp6XNFz1dtHxdjEitQ= Received: by mail-yb1-f180.google.com with SMTP id l139so39506100ybl.12 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=YwCI2DE1lbyBkcIgin7U1uMLp6sh35TlmmXn2Semhzmx/5yGknQVizRnl22bl83d7e OGGZzxhSSNMRxy3avLdxYWkIj+uU5ZGUOBAjGAQcZeaS6aaDvj/Fm6os88xE0lxNlOjH 9yGj8kC1gBZvHgjXzxVsTeRrwmV2Sii5U9lVcgUND1qMdwTeSJl8nqC7D/OjxubGP4on Gem5kxSTljgNimmDyFPzYi6KqkqBqzlINBNUYMcpG7ecgzBUeIowxubE9hJxYRH+EUKq 0uekv8+jIWTVw3ygx9QvSRNLm+8LpyZsa/qKIWKiHwVMijkCg7OggqI78ZBN0z138ri5 C1vw== X-Gm-Message-State: AFqh2ko+l2nt5v5e8C1qT8zZD0e8aQJnpWQdxrHc4wVOE541ATYLaA3M 6HKlwRH/e7MvOteyyg64gUIWudswVgOo2cUOoM8p5g== X-Google-Smtp-Source: AMrXdXvFdbyYmxgjrhbrPZ+DHMRuLbevMB2fbnG5spWSq+oHRVEA8MSUcimroDBHgsm9LSnvYVm1PM3o2CDb/QRmG9U= 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-Rspamd-Queue-Id: B3569A0003 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: inyexcomk5b6uaictycfjb99xgs7qojc X-HE-Tag: 1674071719-385240 X-HE-Meta: U2FsdGVkX199Xs+lVKktH/yiIfoldFKXy9PR/s1nRVMUwVLSHVukXbKkDqCtjLq/Kn5+tvc868pVEbDpDkYSewEx8oKSUcoOzpR+2xv8JfA1DnK8dUTIJoX4At+gSrtwBwChdSrcZRLY/pJy0GGtYO9bX0uzX2iZXOQ/muSSsMd58O9qaKkE+JRTFQpSMSYs3yO3Gz2Nd6neq00TiFpHP7R1l/hY/Dg0+w8UPs3rEn0SfojMEVZG5u79H2BrsbdWxdAmMJgNZj2q26gB9fTIPZKBtwTB5rSGkSRceijG9WtLw9YK3ndtrN4tvi7e4ylOUN4xq5rTszstMubpX7ariB2u3cnfm7nTBQttiwQ6FgiKNjGrUsXXfCt12dvxNG+z23nkfHdtnGHrFBoA++1pVboJVtyhLS++KegEfYL9Kdjmz0AvhBTp1Tu8A3nnC89gWG0bdXHl4kFer7ASyZVVcylXzGiuOjMHdAyr9doK4JSlNnGmQAYTQlEJ1r+p9L78jhMfVqX0s1TBhD3bTWXnDNAQ7sET6350Y5ytDcw37ZmxMG25iNA/PHH0em5AI8XTO3T8lhBReEcLQMGka/6EpWu4XFNial9ICmObBMx+kf8zCNOQcDv6hd9dPbY7Nmz/bhf2X7oW6H3Xr7B4BO9vxnFAQBE66X7GQoGN0vGomriTBvZj6FAqJ+ATHnPOFVkVzIi0ae9OjBOrQm9Y9nvdI+QD23pmqa2GtmE3VA8DVQGN6Q9AliMucZZ2j5Cuhb2vuCBtQwO2+rh31dp2kNH6ocxdrH2iI5Jjr4blCbE174Hl/ZusDMuemVXcXKl46FNHdl40PER1BCYYDsVxt4s+Q5bNAjMpgmPdl1ceHkGUqPLaFyxWDFLuIzrUDEgifGXeTHeL3V12yiDmGTDxqgkzRamFjfxmLicue+htQQso49MLp5FbDQgD5Ifbb5SEbDex/jnMbypfDby8uN4vDlW BD1wJzqC hW5UR+PJXIq/o36EguqK7AGOFhmSFFmlD6wm76NfqrZuENN7vYK4hwTfVl9p7svnknTJrsLUz3G1ZLKWXS+epoYCcPKq0TVFD0lS0JM/jCHPA0YUAj++T1EKs7g51kvXkbzcO9VD1PyIjoppO26EWyLrxTxoyPyjWGA8zIDMzNVXKyVg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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