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 E6BF0C433FE for ; Tue, 1 Nov 2022 19:10:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 485F66B0071; Tue, 1 Nov 2022 15:10:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40EBA6B0073; Tue, 1 Nov 2022 15:10:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 288246B0074; Tue, 1 Nov 2022 15:10:59 -0400 (EDT) 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 16E626B0071 for ; Tue, 1 Nov 2022 15:10:59 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D45B41C698F for ; Tue, 1 Nov 2022 19:10:58 +0000 (UTC) X-FDA: 80085815796.16.361EAB4 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf03.hostedemail.com (Postfix) with ESMTP id 71E9B2002B for ; Tue, 1 Nov 2022 19:10:58 +0000 (UTC) Received: by mail-pg1-f176.google.com with SMTP id q1so14210412pgl.11 for ; Tue, 01 Nov 2022 12:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ybCiLXxO570hJh0cp8N+ATdERuCHgHi9z3YhDIi8Ofs=; b=WAN4MbZaeuCu7QuDgNOSZJtiDENU/81rKlOq5MCPeSV8rn0kaGqJ3HsQPZsIZ0mHHE N3QZ9C/6P9D49RX7wN3fPr3GnjqDIXknsAo1JW/qr5NxaZP3/BcHdiDsmWgikiPAE7HJ vrkA8kmsKtynmZa3c9yrBuEYoKrW0Plui2xIhoQJdZ59EL1w8qa0fVSjBFRgwBV++6pc xsr0/uAOLi6RUfsM6oTkeqpRcxUotlp30hf26g/y3tIMAUnlF2hMABbuGrl+4vRSM5fN TlF7KurDL4SsE4Zd8EIL8SKRmTu4rEm5LwIzTugnKI3v0ScPp2jJVdk2N3Rg82MtcLA5 MxBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ybCiLXxO570hJh0cp8N+ATdERuCHgHi9z3YhDIi8Ofs=; b=jU+Rg0xlq+QUErPHNey4+fa5b/dUkZLXA7rV0fblAQ1sbmokcfK5MeEBtHXyXLHRk0 SGamfadGzTSf8mDzlMbpBvyf039irjbwYt1xpxhRcln3Tg2e1aTV8Nt4WiAyk4370Dkr //wh430d53fGL6Loy7owh6sc6Y3TxqBBJXluHv/CD8AqjN1lHKReWnftEL6fPCn9L1lJ gtdVcIxOMicBhmnSGoU6Zixmh4iRhtKMCzm8BbCkwkiRirhKr/iA5CGZKTEQOej1rp/f oE1cs+milgNTfdyM7a0Gp9LSElxNdb6XeUxx6z8sz2TW3DwKbyR/kz3UEjY/QXFNQQrs QB6g== X-Gm-Message-State: ACrzQf3sooHfVRGkJj2dAEM9NV1ODj8gdrgomfmubn1imeJ0OcOrWKS9 8j6E81+eK0U+NiZ+//l3hD/meA== X-Google-Smtp-Source: AMsMyM5XYVeXqDIhVZ80uo0x2SOxLzKDMY0tvrdTpVqTyz0JnpHZOeFuKxDItYXWt8cANblMSp0pzg== X-Received: by 2002:a05:6a00:158a:b0:56c:e8ce:9e40 with SMTP id u10-20020a056a00158a00b0056ce8ce9e40mr21683338pfk.64.1667329856975; Tue, 01 Nov 2022 12:10:56 -0700 (PDT) Received: from google.com ([2620:15c:2d:3:6d6f:cf8:f6f9:256d]) by smtp.gmail.com with ESMTPSA id l20-20020a170902e2d400b0018689e2c9dfsm6679002plc.153.2022.11.01.12.10.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Nov 2022 12:10:56 -0700 (PDT) Date: Tue, 1 Nov 2022 12:10:51 -0700 From: Isaac Manjarres To: Catalin Marinas , Christoph Hellwig Cc: Catalin Marinas , Greg Kroah-Hartman , Linus Torvalds , Arnd Bergmann , Will Deacon , Marc Zyngier , Andrew Morton , Herbert Xu , Ard Biesheuvel , Saravana Kannan , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 2/2] treewide: Add the __GFP_PACKED flag to several non-DMA kmalloc() allocations Message-ID: References: <20221030084718.GC5278@lst.de> <20221030091349.GA5600@lst.de> <20221101105919.GA13872@lst.de> <20221101172416.GB20381@lst.de> <20221101173940.GA20821@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221101173940.GA20821@lst.de> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667329858; a=rsa-sha256; cv=none; b=7LCCOnjiH7FZv/g1yzUKVYPf5dQ4xPHNilyauWDrWB5ZypmG2D102IaFjT2dWneVs3NvSy 1lU0+rHTvlLEeKp21/z3bOaXpksGMdQA0VAOUurgHsoyYuPOllDGXH70ZcG+OggKcGMZIm yLy2Im3x1YsKeL0yuPPdLGddH3FBRPc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WAN4MbZa; spf=pass (imf03.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.215.176 as permitted sender) smtp.mailfrom=isaacmanjarres@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=1667329858; 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=ybCiLXxO570hJh0cp8N+ATdERuCHgHi9z3YhDIi8Ofs=; b=zwEW6522glQH5rOQQWxg98zXeUdkMjLo3sWaOTNFz27YdJ5IM7Hqx+CDRT0dm91krY8PL7 VKxkhv95uUMY3tdtPlQP5CJAS3nghw8TnxhRxzPKnT8nj4oevu4J5Y1O7BO57qwi2YMgSE n34uq0DI0bOGyWEJ7fF/dxRduitgi+U= X-Stat-Signature: j17kn5s4u6trwdqhuzzxs5a8dgqzqpyz X-Rspamd-Server: rspam09 X-Rspam-User: X-Rspamd-Queue-Id: 71E9B2002B Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WAN4MbZa; spf=pass (imf03.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.215.176 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1667329858-123251 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, Nov 01, 2022 at 06:39:40PM +0100, Christoph Hellwig wrote: > On Tue, Nov 01, 2022 at 05:32:14PM +0000, Catalin Marinas wrote: > > There's also the case of low-end phones with all RAM below 4GB and arm64 > > doesn't allocate the swiotlb. Not sure those vendors would go with a > > recent kernel anyway. > > > > So the need for swiotlb now changes from 32-bit DMA to any DMA > > (non-coherent but we can't tell upfront when booting, devices may be > > initialised pretty late). Not only low-end phones, but there are other form-factors that can fall into this category and are also memory constrained (e.g. wearable devices), so the memory headroom impact from enabling SWIOTLB might be non-negligible for all of these devices. I also think it's feasible for those devices to use recent kernels. > > Yes. The other option would be to use the dma coherent pool for the > bouncing, which must be present on non-coherent systems anyway. But > it would require us to write a new set of bounce buffering routines. I think in addition to having to write new bounce buffering routines, this approach still suffers the same problem as SWIOTLB, which is that the memory for SWIOTLB and/or the dma coherent pool is not reclaimable, even when it is not used. There's not enough context in the DMA mapping routines to know if we need an atomic allocation, so if we used kmalloc(), instead of SWIOTLB, to dynamically allocate memory, it would always have to use GFP_ATOMIC. But what about having a pool that has a small amount of memory and is composed of several objects that can be used for small DMA transfers? If the amount of memory in the pool starts falling below a certain threshold, there can be a worker thread--so that we don't have to use GFP_ATOMIC--that can add more memory to the pool? --Isaac