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=-8.9 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=unavailable 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 29CC7C04EB9 for ; Wed, 5 Dec 2018 12:18:27 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id E221D2081B for ; Wed, 5 Dec 2018 12:18:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="s8+OLwMk"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NelImZEC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E221D2081B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:Reply-To:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version: References:Message-ID:Subject:To:From:Date:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SBKBAb+/TYNcDZWNDz3avMzfbKzaECZBjzmwELEIeac=; b=s8+OLwMkeNPYbj DVFYF/bqQJKm1sAFZJc/yqptF9psPnsoEQ/RUid1BpMSJfsAUxpIwgyu3jAxO74duiQzpFqTXm83y 4V/6LMDtsvLcPSE2oRGYz9FMbS/U/FDcUHA0voWpx4vF9FwOLRMF/JzbUtRKcfpyM8xUKpaWqNVer NmVPqnoGvp7125rwYZv4eNTfbAeEFc5bMuSURxGGlKpQstrZhCnIyEN5bZmCaE6OdBSqc7Sq7H1Sa 1iB4iELaffp85EhJLk4oVfw76YL5mdMy92eMfln5ReEqpE8iCOB5NyUO6ABKO0GAUGfXwEv7DnQOa 7U8cy302tZvAK76dZzHg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gUW8G-0004Qi-4B; Wed, 05 Dec 2018 12:18:24 +0000 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gUW8C-0004NQ-KU for linux-arm-kernel@lists.infradead.org; Wed, 05 Dec 2018 12:18:22 +0000 Received: by mail-ed1-x544.google.com with SMTP id f23so16854432edb.3 for ; Wed, 05 Dec 2018 04:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=1nyp9Tp0fXFj1m2K/gnq1GtTedm38kaXBnm3X/uB8uo=; b=NelImZECs4k9/oUKjG2gsdkH0QS0FMexDO6PiWlegc6w+w36g5K0rqlmBgcGyA6vA3 AuKpJpngC2Y2V40OiewgQAnPDMtmoivXtYQ8yTRZtH5GAR657Aw4OLMck59ZGC+xs6li JeFlvQu1aRipxd1vjTgBU2+Ncm6+gwMF1dU4cEnGcnl3xnaRUzwxZ37xRZW805ykhCMb AQ90AJFeNKaJxZcQKxg9fuEJ5/B1vmQmg9xbG1jpA3PxQydsEKcCdRMu2MbyHIM0bAib bF597ELwDcEACCBxvb4Duh9np2WRUIz4B37RPPz5KYPwjeC6aaa/vkRJd8F/SRfydc15 ZU6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=1nyp9Tp0fXFj1m2K/gnq1GtTedm38kaXBnm3X/uB8uo=; b=K+DxPz4g1L19DEEXrLjXQ5W6kobbPTMtUnOp7TezDq3ZdI+C5Iq/e5gz8Zscoc6bEg ngOlKm1Qmxe386noZplRUgMBKt0KTNN6pyrmvZkJ2yb1LETowOV7MVYmmAgSHLVUuzP0 L4lpIj3IMEYikVLgfvCxb8EgUWBGPK1cV9YNLxjpYtmzBWGYeLqttBrKfBKdQCW6Bozv 8gNYBfAJG4GOJ9RVUNvVwaidugtH0qCXJ46PAKi3IWGXp63fdcZ5/60J3TXXPPOADqYr OY3Kd7tMPeyF373JTbU91cqtkDsb7S2LV0/o+JIhk+d1cCxPz7yRG+8CQhvzn+8p4g1d xt6g== X-Gm-Message-State: AA+aEWYjOILMcCO54XN17PSxaaQ2wQdtNjQAdDggzkk7KO9QcYxcAOOv akTcfFpM3WKARTC0CQhq5AM= X-Google-Smtp-Source: AFSGD/XLNQncObxr/w3IeovEugy5hu4ZbqEkiN6Foo/Dzqysga3MIqBKdkU+ZoTjRLCRJJopdWJlGQ== X-Received: by 2002:a17:906:2083:: with SMTP id 3-v6mr18932433ejq.145.1544012288932; Wed, 05 Dec 2018 04:18:08 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id v11sm5547817edy.49.2018.12.05.04.18.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Dec 2018 04:18:07 -0800 (PST) Date: Wed, 5 Dec 2018 12:18:07 +0000 From: Wei Yang To: Nicolas Boichat Subject: Re: [PATCH v4 2/3] mm: Add support for kmem caches in DMA32 zone Message-ID: <20181205121807.evmslrimsv4pdtza@master> References: <20181205054828.183476-1-drinkcat@chromium.org> <20181205054828.183476-3-drinkcat@chromium.org> <20181205072528.l7blg6y24ggblh4m@master> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181205_041820_669263_F3F131F2 X-CRM114-Status: GOOD ( 21.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Wei Yang Cc: Michal Hocko , Will Deacon , richard.weiyang@gmail.com, Levin Alexander , linux-mm@kvack.org, Christoph Lameter , Huaisheng Ye , Matthew Wilcox , linux-arm Mailing List , David Rientjes , yingjoe.chen@mediatek.com, Tomasz Figa , Mike Rapoport , Matthias Brugger , Joonsoo Kim , Vlastimil Babka , Robin Murphy , lkml , Pekka Enberg , iommu@lists.linux-foundation.org, Andrew Morton , Mel Gorman Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote: >On Wed, Dec 5, 2018 at 3:25 PM Wei Yang wrote: >> >> On Wed, Dec 05, 2018 at 01:48:27PM +0800, Nicolas Boichat wrote: >> >In some cases (e.g. IOMMU ARMv7s page allocator), we need to allocate >> >data structures smaller than a page with GFP_DMA32 flag. >> > >> >This change makes it possible to create a custom cache in DMA32 zone >> >using kmem_cache_create, then allocate memory using kmem_cache_alloc. >> > >> >We do not create a DMA32 kmalloc cache array, as there are currently >> >no users of kmalloc(..., GFP_DMA32). The new test in check_slab_flags >> >ensures that such calls still fail (as they do before this change). >> > >> >Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32") >> >Signed-off-by: Nicolas Boichat >> >--- >> > >> >Changes since v2: >> > - Clarified commit message >> > - Add entry in sysfs-kernel-slab to document the new sysfs file >> > >> >(v3 used the page_frag approach) >> > >> >Documentation/ABI/testing/sysfs-kernel-slab | 9 +++++++++ >> > include/linux/slab.h | 2 ++ >> > mm/internal.h | 8 ++++++-- >> > mm/slab.c | 4 +++- >> > mm/slab.h | 3 ++- >> > mm/slab_common.c | 2 +- >> > mm/slub.c | 18 +++++++++++++++++- >> > 7 files changed, 40 insertions(+), 6 deletions(-) >> > >> >diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab >> >index 29601d93a1c2ea..d742c6cfdffbe9 100644 >> >--- a/Documentation/ABI/testing/sysfs-kernel-slab >> >+++ b/Documentation/ABI/testing/sysfs-kernel-slab >> >@@ -106,6 +106,15 @@ Description: >> > are from ZONE_DMA. >> > Available when CONFIG_ZONE_DMA is enabled. >> > >> >+What: /sys/kernel/slab/cache/cache_dma32 >> >+Date: December 2018 >> >+KernelVersion: 4.21 >> >+Contact: Nicolas Boichat >> >+Description: >> >+ The cache_dma32 file is read-only and specifies whether objects >> >+ are from ZONE_DMA32. >> >+ Available when CONFIG_ZONE_DMA32 is enabled. >> >+ >> > What: /sys/kernel/slab/cache/cpu_slabs >> > Date: May 2007 >> > KernelVersion: 2.6.22 >> >diff --git a/include/linux/slab.h b/include/linux/slab.h >> >index 11b45f7ae4057c..9449b19c5f107a 100644 >> >--- a/include/linux/slab.h >> >+++ b/include/linux/slab.h >> >@@ -32,6 +32,8 @@ >> > #define SLAB_HWCACHE_ALIGN ((slab_flags_t __force)0x00002000U) >> > /* Use GFP_DMA memory */ >> > #define SLAB_CACHE_DMA ((slab_flags_t __force)0x00004000U) >> >+/* Use GFP_DMA32 memory */ >> >+#define SLAB_CACHE_DMA32 ((slab_flags_t __force)0x00008000U) >> > /* DEBUG: Store the last owner for bug hunting */ >> > #define SLAB_STORE_USER ((slab_flags_t __force)0x00010000U) >> > /* Panic if kmem_cache_create() fails */ >> >diff --git a/mm/internal.h b/mm/internal.h >> >index a2ee82a0cd44ae..fd244ad716eaf8 100644 >> >--- a/mm/internal.h >> >+++ b/mm/internal.h >> >@@ -14,6 +14,7 @@ >> > #include >> > #include >> > #include >> >+#include >> > #include >> > >> > /* >> >@@ -34,9 +35,12 @@ >> > #define GFP_CONSTRAINT_MASK (__GFP_HARDWALL|__GFP_THISNODE) >> > >> > /* Check for flags that must not be used with a slab allocator */ >> >-static inline gfp_t check_slab_flags(gfp_t flags) >> >+static inline gfp_t check_slab_flags(gfp_t flags, slab_flags_t slab_flags) >> > { >> >- gfp_t bug_mask = __GFP_DMA32 | __GFP_HIGHMEM | ~__GFP_BITS_MASK; >> >+ gfp_t bug_mask = __GFP_HIGHMEM | ~__GFP_BITS_MASK; >> >+ >> >+ if (!IS_ENABLED(CONFIG_ZONE_DMA32) || !(slab_flags & SLAB_CACHE_DMA32)) >> >+ bug_mask |= __GFP_DMA32; >> >> The original version doesn't check CONFIG_ZONE_DMA32. >> >> Do we need to add this condition here? >> Could we just decide the bug_mask based on slab_flags? > >We can. The reason I did it this way is that when we don't have >CONFIG_ZONE_DMA32, the compiler should be able to simplify to: > >bug_mask = __GFP_HIGHMEM | ~__GFP_BITS_MASK; >if (true || ..) => if (true) > bug_mask |= __GFP_DMA32; > >Then just >bug_mask = __GFP_HIGHMEM | ~__GFP_BITS_MASK | __GFP_DMA32; > >And since the function is inline, slab_flags would not even need to be >accessed at all. > Hmm, I get one confusion. This means if CONFIG_ZONE_DMA32 is not enabled, bug_mask will always contains __GFP_DMA32. This will check with cachep->flags. If cachep->flags has GFP_DMA32, this always fail? Is this possible? -- Wei Yang Help you, Help me _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel