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 AEAEDC54E94 for ; Thu, 26 Jan 2023 05:04:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAD0C6B0071; Thu, 26 Jan 2023 00:04:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E36226B0072; Thu, 26 Jan 2023 00:04:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD8E86B0073; Thu, 26 Jan 2023 00:04:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B90186B0071 for ; Thu, 26 Jan 2023 00:04:54 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 755D614040B for ; Thu, 26 Jan 2023 05:04:54 +0000 (UTC) X-FDA: 80395760508.30.89F5111 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf22.hostedemail.com (Postfix) with ESMTP id B0BD7C0010 for ; Thu, 26 Jan 2023 05:04:52 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="j/LKANNa"; spf=pass (imf22.hostedemail.com: domain of jstultz@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=jstultz@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674709492; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DiMArbdV/T0/c00vu6b8fiK7TVndbh70egFu73S7mgY=; b=PmH5+qrQeYmEEogTeT8q+OBSrmx7Ut1vC9jzLbqKpnTvxZwIU8+8pObiZs02mRHBW36Ogt SdN1W5jXvT9cEYwEwESgL25P2YxcFmEAPCHnQCNPkoiJSJOfeA/rdqF4q8RQo0HC9egjWw a2KPiW1Iljm/6GF6bpqJm38BCprrjfg= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="j/LKANNa"; spf=pass (imf22.hostedemail.com: domain of jstultz@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=jstultz@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674709492; a=rsa-sha256; cv=none; b=v1D5y2XOBs6aRvk6GrkvZ7v1vN42OsRt+qtirSH69whviVgpxAMxZ+QJstROMcAUWGQyYU 9DBiRKeDcWDa06ztBrxdyl0h4jIz7i9S2clXMYb1YWafi0erqiAv7XXnhgT3NGZBgkjSee ntUoLVM5o/Hh9W/rlcbNRIHWxjNNU5w= Received: by mail-yb1-f177.google.com with SMTP id h5so741709ybj.8 for ; Wed, 25 Jan 2023 21:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DiMArbdV/T0/c00vu6b8fiK7TVndbh70egFu73S7mgY=; b=j/LKANNaDiV/aVUigkiPOcRVnzC0NEKIE5OVSqZFXO5PQmA8IB4O6ybyFs7K9nHv5e laSl/lOwAbh+AdgJ1eP2IphhzkEB7ecxZcjDktRE3b7n6EfL5C19sLZ43AqeRBfb0KtA R6bpp2jKN9ETwo60eIyTxSUyaKK5Do9xQQjYLkEb5WyGf3LUpoxQ5pBOAkUzfJdMuySn /86Tg01i6EE+kVVaHoYAzQ0fo3EJsMxn11gTJmXMNVyZ5V6Yfmz133yEbMijwhoIplf+ 2aV4ifCQegjZ71ujLZnnBTPJJUNRx3qFktIIvJIE/PK6s26dYj4szNUqSVjykNzyKJOV 26mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=DiMArbdV/T0/c00vu6b8fiK7TVndbh70egFu73S7mgY=; b=2r/+IvTwe8ztfd4CR5pDnOmnQUFG3dpD70C+O83HV646qTPdOot3FL/65+FGij+lEt hwTRrpNJsMPvm2sSzLEQoKl95TIngsm7V9QOK3HSNjkWNMg77ZvwMXtMWW0lc+SSs4uQ ZEuzB1vGtpH2CQ+z4R6dBiRIQo+WxQX0batmVjRes/w5nc6S05feeG1rU8jNKJLgTC5M mGc3lN2cCf8bIX+7biYeghGyrgfDan/sYcUopN2/sUdVwduXKMdg7aYPEGyk6k4naj5P E8uQO72AMwQ62xhIFdaGpjB3kdlDPkPg03qwLABFAGmylAx8bJl8C+RESwKdINNVAMlR 1+NA== X-Gm-Message-State: AFqh2kozpoXOdhLFd2Cjn3rMHZ0Tj9AnVcCAtO/+The1uCH+B4Cc7V2Q I98cO+8MuJg/5NJEjyyJ2E42do62GBzfvbt79PLE X-Google-Smtp-Source: AMrXdXvqx4UwR/r3vyZL8yNah3Pa9DYRDPjFsXDYhXUxO9RFX6K9KBd57NKlJxTw0JZEjJN84sol+jsPKtLhpA9OJvo= X-Received: by 2002:a5b:84d:0:b0:7ba:e354:5aaf with SMTP id v13-20020a5b084d000000b007bae3545aafmr4010311ybq.37.1674709491637; Wed, 25 Jan 2023 21:04:51 -0800 (PST) MIME-Version: 1.0 References: <20230117082508.8953-1-jaewon31.kim@samsung.com> <20230117083103epcms1p63382eee1cce1077248a4b634681b0aca@epcms1p6> <20230125095646epcms1p2a97e403a9589ee1b74a3e7ac7d573f9b@epcms1p2> <20230125101957epcms1p2d06d65a9147e16f3281b13c085e5a74c@epcms1p2> <20230126044218epcms1p35474178c2f2b18524f35c7d9799e3aed@epcms1p3> In-Reply-To: <20230126044218epcms1p35474178c2f2b18524f35c7d9799e3aed@epcms1p3> From: John Stultz Date: Wed, 25 Jan 2023 21:04:39 -0800 Message-ID: Subject: Re: (2) [PATCH] dma-buf: system_heap: avoid reclaim for order 4 To: jaewon31.kim@samsung.com Cc: "T.J. Mercier" , "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" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: cxyhq35414h1p6p6pa7fy9dikmcdawda X-Rspam-User: X-Rspamd-Queue-Id: B0BD7C0010 X-Rspamd-Server: rspam06 X-HE-Tag: 1674709492-641946 X-HE-Meta: U2FsdGVkX19uvFofrHXYFh/Se31HuBuMKvzAWScdFuymZ1OVra5q+3LY3GsNBUzhXAKuMkTcRF+m0Vlmv7Ky2xAb3BT6Jon8xn3l1U1t9p5cvLp+lZWQPBsVPwjsOCSh6ZXM4ZxrxvrM9Y878l4OrgMYdxCaXGILm6EG2G7HudXdtWAZgsl62zpOzsTOSNGe6ajHmajjo6yQn2l+/8svwj75cjc48r1kqqopo8NJMQmt7r/e99KICYvceByA6SJIwKuYB1/l7DfxQFd8JE7jGYLfF7uVry+dSNTL/+pp2PJ/WU6y3d5uviyQNKKkdzm95RgAwJ0zEtWgsziPbQi25OuY+QY7jNNhoerB1P97kNlnrW+YSNjZXlfZPzMZpZUwAhRKO6bpxaXlVUeMfsi041pC+qSUIB/+7dswQs3RFyYlrEkOhxe4K5bsS9+YG2KsoC/UeK05xwGaDNbzi2hBtWi1m93LyI7UHj6ynaNV08O57WbdZMu+hIfdY9Y1jsL8imkivsMZeLjiH9W/sClB7ff9wljgfmeDinTb8rCmpREHLGAbC9h4TAJ6xAkYt5L/TdFy+Duvm4R2J8SQ9rQgB7UYwOL//3bRk5l8q3fR7lNojlX9HfCNnMqMY79wbN8hphKQRe+t7xsgXkVR+DUOKsEDFKKix0UhW/zvE/OpE8X5GTcad0AbkWkUihQK+OUreYrnkT/hvAbm+3xaGsxfU7uZ6yAstFSTx1xPZ2wN4PyfBVk06U+kB+gXBYcFftdfDkhkYT5BdurVBkvqyOJgGTnRVUsf8kIN4XF6NkT6ztPZNs2BCvuXvHUIMTphL9hCqqe8GRM1MO2x+zqaWQyJkxsoFFnUJTWzOoJylTxacc0xFV+lyUCa3ulYuDrdf6ET/gKQdwcMVKxD214zkVWFPh8c5QG4V8prsgGZlHUG2pKr8JrZwhrfYpuaNWEWGLaXUR7RNLFmqscr76nqaie TBXSLSWu gdjLdtQuTGBSzgxC+R/LidmyE89L3m7n63zLeos4xbs9e5ue0EA5WFxA5ipx2QdAL+aL89fGL+SMrM3SAwPKEyq/X1teUeU6eGZUK3afRE1mFNaAkudEdi5fFdRHZMYxRv2wkvQ8VRgJMM0AluUAMh4KZUmW3SIJsKi4D56VXEiupMHZbohjUmlR1AxcQSGNlNWnaj94hS/KrvOnhaccHgpefBQq6HCD23QM2Zg7sGYlH/i/CY2i4JlPxUfDpatDMDyIYxnEF65dgt31P4SR5jdq8ezJtHGM1PRFqpBn9dHJTbanX+Ubr5Foi7R1k628c6fmYi4B4LrElllcLjtDhhYDH7NaKGaEnS5V/0Oz8DDqirLbXwVQh2OUAAY5flU/4g+UtOnPzBdkeG8wwzxUykt5cZCgOxbBJ59S2ryOK6X09XQbvBeJlEdOJYm4EaSAKlEQRt7iqQlWstko= 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 Wed, Jan 25, 2023 at 8:42 PM =EA=B9=80=EC=9E=AC=EC=9B=90 wrote: > > On Wed, Jan 25, 2023 at 2:20 AM Jaewon Kim w= rote: > > > > > On Tue, Jan 17, 2023 at 10:54 PM John Stultz = wrote: > > But because your change is different from what the old ion code did, I > > want to be a little cautious. So it would be nice to see some > > evaluation of not just the benefits the patch provides you but also of > > what negative impact it might have. And so far you haven't provided > > any details there. > > > > A quick example might be for the use case where mid-order allocations > > are causing you trouble, you could see how the performance changes if > > you force all mid-order allocations to be single page allocations (so > > orders[] =3D {8, 0, 0};) and compare it with the current code when > > there's no memory pressure (right after reboot when pages haven't been > > fragmented) so the mid-order allocations will succeed. That will let > > us know the potential downside if we have brief / transient pressure > > at allocation time that forces small pages. > > > > Does that make sense? > > Let me try this. It make take some days. But I guess it depends on memory > status as you said. If there were quite many order 4 pages, then 8 4 0 > should be faster than 8 0 0. > > I don't know this is a right approach. In my opinion, except the specific > cases like right after reboot, there are not many order 4 pages. And > in determinisitic allocation time perspective, I think avoiding too long > allocations is more important than making faster with already existing > free order 4 pages. I suspect you are right, and do think your change will be helpful. But I just want to make sure we're doing some due diligence, instead of going on just gut instinct. Thanks so much for helping with this! -john