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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CDD8C07E9E for ; Wed, 7 Jul 2021 19:35:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 344EA61C77 for ; Wed, 7 Jul 2021 19:35:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232364AbhGGTiS (ORCPT ); Wed, 7 Jul 2021 15:38:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229519AbhGGTiR (ORCPT ); Wed, 7 Jul 2021 15:38:17 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8729AC06175F for ; Wed, 7 Jul 2021 12:35:36 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id n14so7015637lfu.8 for ; Wed, 07 Jul 2021 12:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8r2Sihww/r2eDq532jyXn6fdk4Gdh3BwgDNIfLgaV/E=; b=MszDYgh+2NKqhOHbW6T5LEDSW9GergXNfLJILyRlimCcLRDhvW35rAjdXYDUOohkVo wHdpvCXENIyxge/RR1xi+LcJozdm2KYSM6ty7uAy2OpcI06vVjK12HCKxqbEndRHk9Cb TyANaMtKc4b6zf+KsQEe8ku5flehh9j9ipk0jUaKUQeixBjw+ghFN2nGBgUAoSXGVVb2 CAoq/zr7DNXYTeimJi4DXHo1zfyu3X1Kk3MwEbq+p+GDEsObLp2GImtWTJWiuPHkHTgo cU34/ShPKF6Rem9Fo1O4//yhd3uepwZYFdVbHvlE2UK2DWipfOsqxfPEw9toHb8HxW6H 0kZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8r2Sihww/r2eDq532jyXn6fdk4Gdh3BwgDNIfLgaV/E=; b=Q8h7DSDHamNNGw7jRQkvfIfySEBEDSLa08R+sc5qYwBTcfMEI/xgje3h9rRKqpqfra 85/TV3uFofsgnvAV1yXzoo3hwtlCnuCS6eNTapKxy0Emu6EIp62ZUML5SwrmN+7WPrCQ oradR84UAd1kHY8My24j5KTBnHgYUgGqk9PQ8HcQAOeFVvObLhZqJbigcPJoEN9hI20r 0BlMgv8g/B25xZmlbV70OM10GC8ODp9yQRoC4A6/Au/npwECJ7OH29qNcAD12LFRttOR VcOnZ18ArknxwoPHcSglVpX/Lk0yHydgk6tBuIiv9+GUw/zh8SXGoCjiCMYrzbgPjE9U Xhhg== X-Gm-Message-State: AOAM532hq5dZB/8x+RHwd1OpnGIXzEpu5DYJrPG5qDiUAu0HI6HZBkYS O6sw/MBcI0l1v9rcN7N+c3P/sa4wCN4XsRyJ2kaA4Q== X-Google-Smtp-Source: ABdhPJzq0vYBbcbRJcpJ1wm18X49R0cZKa1F2pwLnWsMpB+SU+peQArLpyP1JAM9LeGI4+7Rz1ZU9cgjkoNN3RCUOQg= X-Received: by 2002:a05:6512:2246:: with SMTP id i6mr11859231lfu.7.1625686534805; Wed, 07 Jul 2021 12:35:34 -0700 (PDT) MIME-Version: 1.0 References: <20210630013421.735092-1-john.stultz@linaro.org> <20210630013421.735092-2-john.stultz@linaro.org> In-Reply-To: From: John Stultz Date: Wed, 7 Jul 2021 12:35:23 -0700 Message-ID: Subject: Re: page pools, was Re: [PATCH v9 1/5] drm: Add a sharable drm page-pool implementation To: Christoph Hellwig Cc: lkml , Daniel Vetter , Christian Koenig , Sumit Semwal , Liam Mark , Chris Goldsworthy , Laura Abbott , Brian Starkey , Hridya Valsaraju , Suren Baghdasaryan , Sandeep Patil , Daniel Mentz , "??rjan Eide" , Robin Murphy , Ezequiel Garcia , Simon Ser , James Jones , linux-media , dri-devel , Mel Gorman , linux-mm Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 6, 2021 at 11:38 PM Christoph Hellwig wrote: > On Wed, Jun 30, 2021 at 01:34:17AM +0000, John Stultz wrote: > > This adds a shrinker controlled page pool, extracted > > out of the ttm_pool logic, and abstracted out a bit > > so it can be used by other non-ttm drivers. > > Can you explain in detail why you need a differnt page pool over the one > maintained by the page allocator? Fragmenting the memory into all kinds > of pools has lots of downsides, so the upsides need to be explained in > detail. So, as Christian mentioned, on the TTM side it's useful, as they are trying to avoid TLB flushes when changing caching attributes. For the dmabuf system heap purposes, the main benefit is moving the page zeroing to the free path, rather than the allocation path. This on its own doesn't save much, but allows us to defer frees (and thus the zeroing) to the background, which can get that work out of the hot path. thanks -john