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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25B18C4332F for ; Tue, 1 Nov 2022 19:12:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dJKYuZSfoD2he0I4354+KH50PvsNj8zrLtDmdwvu+YU=; b=24iiEAsuP5aW+L aBhceF8kyQxlQ+NLHKf2h0DLpLvyrj36MZM5iJUnJ5R2K6wiNiXDvxGotAk1pqnWRx88Hhp1jOaga 6gPe77lceB9VD5yCRgtR6W8B9HehjFdwXbTtFOY1NSenCGVMIKRndqR626fiEP79Abcfq9pLhEpWS A/S6J26H9aWTh93GL9uMlIhvjf4GvVFefQl8+iCgLRaMvO4QbOLZzOziIZ1yFEA0nhx70oTdkEpUu xOrlkcNHw0/nHe9b/8ohpfvvQyfxs015xm1vCDm578CKfF/fKQdheIJ7skC0nX0F1RU3fQ/7xOX0Q zWrDMviQ1PiIsPm043gg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1opwfB-006de2-Nd; Tue, 01 Nov 2022 19:11:05 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1opwf8-006dYc-P3 for linux-arm-kernel@lists.infradead.org; Tue, 01 Nov 2022 19:11:04 +0000 Received: by mail-pf1-x432.google.com with SMTP id b29so14297129pfp.13 for ; Tue, 01 Nov 2022 12:10:57 -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=gKV/TO9AyQrThUofqzOe5+NPCLaRqlE5Wot0Ek66aeN0GrVlKcEPlGBL+vbxszWq5e z6JSymxQRAfljN2SuGAMxlK3AFdPD8ROiCZSKIPcjlBIt3/kSmrard3OWaAzC1/Kw0Rx /OMdwf8mnhialIcrqHphBY5HQS028O/NQKlz7ddhC3uuzRpamrOD4EHD1COIWRDlDqr9 dEhdXBhM2moiXoKet69bU5YX9kOIfO08SlFILr+yYBPZJhvB3hJHOg7g+Jx9NXozL5Ct 0xGKNrYlGprLEps2aGH5B/AGwlz9c1LCh9Xs8rGOkUGtGHOcJGx0ZOjVQpIwiYTS9Pz/ t3Qw== X-Gm-Message-State: ACrzQf1fv21S1WVP+7CRBe8O99HqBe7QbGUA+x1de+9eXKEaj9qLrS2g 7FSu3/NvaCgZpl38nvEpSWDFn4bm5m3fpg== 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-Disposition: inline In-Reply-To: <20221101173940.GA20821@lst.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221101_121102_849451_B69FE705 X-CRM114-Status: GOOD ( 25.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel