Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1193235imu; Thu, 22 Nov 2018 11:51:35 -0800 (PST) X-Google-Smtp-Source: AJdET5drgMLTrhD5jLlHYupWlSbPF6bKwlkzMbMC/juwq3EsXCANQc5TSGPSep7yNQKyJC8+vkRb X-Received: by 2002:a62:1043:: with SMTP id y64-v6mr12955013pfi.79.1542916295320; Thu, 22 Nov 2018 11:51:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542916295; cv=none; d=google.com; s=arc-20160816; b=i+qQxmLJVskRwJwDkXJv3PfEBIH+z+UXnxdKkkUT+sAAfmBQ4SLTIz3AKzQZkt+FFF TtAAil0imiGrM4GjuIFC7pS6Xgt3OqbVMrgK4MftHeqBItFnwfiChC8ZaIY36IAA8DJO +AFEIq3SEwzYoeANcIy08060ePGzPo+lnuxwMBTmqtwOywmV/VfQs9QitcCKt8QWnc6i ekHDm5Nz/V9sTF3WK4WXaEkWgyCUcOKZ+EbhF+8xCo14fNYMqleK2Du8/RULG9sJuigX zDzNgyyX4OWoY8J+uIqO0VdIpJ1kDxbsSbcsC4MlFoB/Ozm0wNgNnukVZ2ugiUtKvoNj rSvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=YrZXzotn0Tvsd23WJeb0DHM4K95e7RT6B2jqKEtwu00=; b=J3X4zFuBejmk7VCEUZqpJ7nUDk+H0AYJPqheGQx1PCKhyqVmjvxEv6eXq8KbtX0kWr cv8xuvW01icbC1tNPG7djJQ0HvGNThaO/yIpzOmdYJ2vvrjLJQ+dKZGOQ3D5HcwpV5at DzyUVYj09qFd//U00z6+F916iT6fmkxgPvQTrWD56Lqc2DJqFtdydkEDeoeApUvxuLaZ hS0KXxjncuQxftz+KgvbVUDiXuyAShdMjLwKrjJy3e4c2RXGTKjqECDMbxbCUv0jdHuu jJ7VX2aT+5sT7bPhTKUgMTJZzLavJRdvM1RH13i9ynGYDA20bByRGxmae2pLUHEXcuFw zt8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jQraFxVb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w22si2244456pgk.589.2018.11.22.11.51.20; Thu, 22 Nov 2018 11:51:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jQraFxVb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404619AbeKVQew (ORCPT + 99 others); Thu, 22 Nov 2018 11:34:52 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:41026 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731512AbeKVQev (ORCPT ); Thu, 22 Nov 2018 11:34:51 -0500 Received: by mail-pf1-f194.google.com with SMTP id b7so1389648pfi.8 for ; Wed, 21 Nov 2018 21:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YrZXzotn0Tvsd23WJeb0DHM4K95e7RT6B2jqKEtwu00=; b=jQraFxVbMqZcP6TpRxJrNLkbOt448O6pOdI82iDORaiJZTopAzHF6BgbgJW4C3nt3d l16bM/icrk+3BEzSlerLMLg14b9DoLhUofViVNJTxliVWzMOpZn01d8+kC0lTUKmOz7l 9wuDw8pe21OyemQFzVsPz5z2Q3x/YpjuyQ7jY= 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=YrZXzotn0Tvsd23WJeb0DHM4K95e7RT6B2jqKEtwu00=; b=jFU6630PQLYdT2YHXgelrPrj36H/upB1y2gWPojgwOI2W9LKdvw8ZSh4BVSizE/nu4 JnT563zIp6VbkHBdhAhJc8WZBpcrYG3VlkGmDUNDNhwgqBxpn2VIR2SCPy3UqLP55Ix5 QJWlyWA7KOdMMV8pwEluHmuL22V/Am/RkfwZyi83+42yIMeWdTYtl0b9zlF5Nqp+9n0C RY0SIMsOpA1nI0BZ4cRg5H4eC3krNZtjF5UItENWdx9n9neWhqMx7KCysk/qgY32cP22 srMXTZTASy8H3Wpos0q66iy2epCgXygK0mrzdaC8i96G/GNBfY/pBl1QPQamghNUTWDg GJtA== X-Gm-Message-State: AA+aEWYGoKPjphhlIXpdJeUGleG+U+AFRecMqDskHXGAAmSu3FRxSSA+ kQab/YshZUEUsvQsVNWoJM76gyknvTIpkvCnf/6u8w== X-Received: by 2002:a63:fb46:: with SMTP id w6mr8877025pgj.321.1542866219107; Wed, 21 Nov 2018 21:56:59 -0800 (PST) MIME-Version: 1.0 References: <20181111090341.120786-1-drinkcat@chromium.org> <0100016737801f14-84f1265d-4577-4dcf-ad57-90dbc8e0a78f-000000@email.amazonses.com> <20181121213853.GL3065@bombadil.infradead.org> <20181122023558.GO3065@bombadil.infradead.org> In-Reply-To: <20181122023558.GO3065@bombadil.infradead.org> From: Nicolas Boichat Date: Thu, 22 Nov 2018 13:56:47 +0800 Message-ID: Subject: Re: [PATCH v2 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables To: willy@infradead.org Cc: Robin Murphy , Christoph Lameter , Will Deacon , Joerg Roedel , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Michal Hocko , Mel Gorman , Levin Alexander , Huaisheng Ye , Mike Rapoport , linux-arm Mailing List , iommu@lists.linux-foundation.org, lkml , linux-mm@kvack.org, Yong Wu , Matthias Brugger , Tomasz Figa , yingjoe.chen@mediatek.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 22, 2018 at 10:36 AM Matthew Wilcox wrote: > > On Wed, Nov 21, 2018 at 10:26:26PM +0000, Robin Murphy wrote: > > These are IOMMU page tables, rather than CPU ones, so we're already well > > outside arch code - indeed the original motivation of io-pgtable was to be > > entirely independent of the p*d types and arch-specific MM code (this Armv7 > > short-descriptor format is already "non-native" when used by drivers in an > > arm64 kernel). > > There was quite a lot of explanation missing from this patch description! I totally agree ,-) I'm not familiar at all with either iommu or mm/... Looks like the patchset triggered a helpful discussion, and I understand the problem better now. I'll improve the description in the next revision. > > There are various efficiency reasons for using regular kernel memory instead > > of coherent DMA allocations - for the most part it works well, we just have > > the odd corner case like this one where the 32-bit format gets used on > > 64-bit systems such that the tables themselves still need to be allocated > > below 4GB (although the final output address can point at higher memory by > > virtue of the IOMMU in question not implementing permissions and repurposing > > some of those PTE fields as extra address bits). > > > > TBH, if this DMA32 stuff is going to be contentious we could possibly just > > rip out the offending kmem_cache - it seemed like good practice for the > > use-case, but provided kzalloc(SZ_1K, gfp | GFP_DMA32) can be relied upon to > > give the same 1KB alignment and chance of succeeding as the equivalent > > kmem_cache_alloc(), then we could quite easily make do with that instead. > > I think you should look at using the page_frag allocator here. You can > use whatever GFP_DMA flags you like. I'll try that. Thanks!