Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1062637imm; Wed, 23 May 2018 09:39:54 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqK4POb/T6dYGPnyriey3C9vItGwv7iFOOgCvEPg7DqqRSrFqAl4rZvz+31c0xyz0OGr2td X-Received: by 2002:a17:902:6181:: with SMTP id u1-v6mr3639328plj.272.1527093594922; Wed, 23 May 2018 09:39:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527093594; cv=none; d=google.com; s=arc-20160816; b=qkJ+RRBoy3bWRgPPcuaDtOlEoz+htTpWbm7oKc+Z2H3RRhZ51+Q462QPdluKr4JYAZ X4Ef25BTJmfCgJgLa+QLTpkpSx48nrYFUmTFy7hq0oBEc5nRvLfY1nUUJtnKCc1Ihedm nmEYYPcu+2WTZhzV/fe4WGMj2SzWn0N3OXIG7i3lswvahLnNDVA+t/4EgmbHRk/Jv5CV aIfyIs7WRT66s2Z4kmyCDtBPNnnQ3xRdpV2/09Ku4TzG8Vqwy2BwRquvzk6qgG1fjBq9 QrtJ5V7hJDZSDtTpkq9zqqgivfwz1nZkAJZX5xVGIXErchKo1zuHuw/SEnKzzfm/b31p SnaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=Yz2M4nFfcrvb0NcPST1MDnDeJx8G0pwYuNvt8bUceFc=; b=cXwZLLd3HVWKBOlESf8fy6Ne4nk3uYrNEaKhegOW3xOsTQm/0as4hj0IWv1M2sATWR q8fN1vUqkBCFiTynPqyeeguqd5Fway1HaPnXjv/Yf1hG/16fgA/r7QpSAX+bOO5sXY5p R1hPofm6rMv8Ui2rNMCdNbGXYjOCGwLBB3D6jJizquLJL70RHEaz0yPicIrkcW3Tkn3d u/u5fAlUtAWhB3GhfysvmARqf5byoikdBwgHQLdvD9eUrMfVsdg5WSu2hON9+tfh8w5c iZXrn8RY3oV3k8EI5Mq9tEjo9D7SyeiybhbGO/ujIIHf4UavkdlKjjzKwczvhmJsKX56 hgvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QDvjypDa; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h125-v6si13198327pgc.34.2018.05.23.09.39.39; Wed, 23 May 2018 09:39:54 -0700 (PDT) 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=@gmail.com header.s=20161025 header.b=QDvjypDa; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933513AbeEWQiN (ORCPT + 99 others); Wed, 23 May 2018 12:38:13 -0400 Received: from mail-pl0-f66.google.com ([209.85.160.66]:32930 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754623AbeEWQiE (ORCPT ); Wed, 23 May 2018 12:38:04 -0400 Received: by mail-pl0-f66.google.com with SMTP id n10-v6so13368502plp.0; Wed, 23 May 2018 09:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=Yz2M4nFfcrvb0NcPST1MDnDeJx8G0pwYuNvt8bUceFc=; b=QDvjypDaP1F+VVSXeZjNoMEMUyhRXVahaLydMNEyV6XZHBqFHX2PTXlLg9aSCk21rV ss5egP912QzzyjG9Sf38Y3+A+sftdsyH3iikDspX5mT1tWszvF8ITfmpYgDBrumI2ZaH QGvTHDrI8TIC40Kzzos+WDIO5MORoLiWyzZUlorZ2VTQZwYIY4hktdvflFda/YapQU1X v7TIYyk/Nz9RX71HsxfKum5qwgA4Eog9a+Z9WQr4byRRhl3SoWk4mJkTUNlgHr8yuNvv 5eCwNjiE2bONX7KcLmMWkFpQTVaVYS5lKtKpWOmyKKzZ1DytrC8bxMGhptQ7wyB5EIJr gmCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Yz2M4nFfcrvb0NcPST1MDnDeJx8G0pwYuNvt8bUceFc=; b=hNh4RUcXi1ya17OvSpZ6fWmiEDsS1YdJcoqyr6Ml5fKkhFmvVraIsrDny/c3qQq2fb +QMv1jlxrv0LR7oHD0R38i9LqENPY9+02cemF3jRTOG4UFnuNb0wHjVsh/19Mp79xOgJ skcit0xeTD+OZd0Dxg9U5tq4OxuZOc2z7WkZ5ErCxdTqilNWfXQlW0P24ohqmzpUZQTK IBnD0gzzh68Ac2jtClKfHX7b6SPRK7gWP1FDX2VHzR2nvkpTNACyMhT5wU0TfX5H5tXN M0g9//JasvZp36XkyF2LPGvhqZ13pU8HAxuFzVq3xQIZGqoWVHz+gzYbPttoabty9ibh rQyg== X-Gm-Message-State: ALKqPwfNMbuXWZvP7NHyKlbZtFxbzKgj4ei+fWgbXDvNZLSSorqdz51f moROGfd51Vvr3Vhki3Vz2Tw= X-Received: by 2002:a17:902:4301:: with SMTP id i1-v6mr3686518pld.280.1527093484014; Wed, 23 May 2018 09:38:04 -0700 (PDT) Received: from localhost.localdomain ([123.120.56.60]) by smtp.gmail.com with ESMTPSA id b6-v6sm41683369pfe.34.2018.05.23.09.37.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 09:38:03 -0700 (PDT) From: Huaisheng Ye To: akpm@linux-foundation.org, linux-mm@kvack.org Cc: mhocko@suse.com, willy@infradead.org, hch@lst.de, vbabka@suse.cz, mgorman@techsingularity.net, kstewart@linuxfoundation.org, gregkh@linuxfoundation.org, colyli@suse.de, chengnt@lenovo.com, hehy1@lenovo.com, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, xen-devel@lists.xenproject.org, linux-btrfs@vger.kernel.org, Huaisheng Ye Subject: [RFC PATCH v3 0/9] get rid of GFP_ZONE_TABLE/BAD Date: Thu, 24 May 2018 00:37:35 +0800 Message-Id: <1527093455-3899-1-git-send-email-yehs2007@gmail.com> X-Mailer: git-send-email 1.8.3.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Huaisheng Ye Changes since v2: [2] * According to Christoph's suggestion, rebase patches to current mainline from v4.16. * Follow the advice of Matthew, create macros like GFP_NORMAL and GFP_NORMAL_UNMOVABLE to clear bottom 3 and 4 bits of GFP bitmask. * Delete some patches because of kernel updating. [2]: https://marc.info/?l=linux-mm&m=152691610014027&w=2 Tested by Lenovo Thinksystem server. Initmem setup node 0 [mem 0x0000000000001000-0x000000043fffffff] [ 0.000000] On node 0 totalpages: 4111666 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 23 pages reserved [ 0.000000] DMA zone: 3999 pages, LIFO batch:0 [ 0.000000] mminit::memmap_init Initialising map node 0 zone 0 pfns 1 -> 4096 [ 0.000000] DMA32 zone: 10935 pages used for memmap [ 0.000000] DMA32 zone: 699795 pages, LIFO batch:31 [ 0.000000] mminit::memmap_init Initialising map node 0 zone 1 pfns 4096 -> 1048576 [ 0.000000] Normal zone: 53248 pages used for memmap [ 0.000000] Normal zone: 3407872 pages, LIFO batch:31 [ 0.000000] mminit::memmap_init Initialising map node 0 zone 2 pfns 1048576 -> 4456448 [ 0.000000] mminit::memmap_init Initialising map node 0 zone 3 pfns 1 -> 4456448 [ 0.000000] Initmem setup node 1 [mem 0x0000002380000000-0x000000277fffffff] [ 0.000000] On node 1 totalpages: 4194304 [ 0.000000] Normal zone: 65536 pages used for memmap [ 0.000000] Normal zone: 4194304 pages, LIFO batch:31 [ 0.000000] mminit::memmap_init Initialising map node 1 zone 2 pfns 37224448 -> 41418752 [ 0.000000] mminit::memmap_init Initialising map node 1 zone 3 pfns 37224448 -> 41418752 ... [ 0.000000] mminit::zonelist general 0:DMA = 0:DMA [ 0.000000] mminit::zonelist general 0:DMA32 = 0:DMA32 0:DMA [ 0.000000] mminit::zonelist general 0:Normal = 0:Normal 0:DMA32 0:DMA 1:Normal [ 0.000000] mminit::zonelist thisnode 0:DMA = 0:DMA [ 0.000000] mminit::zonelist thisnode 0:DMA32 = 0:DMA32 0:DMA [ 0.000000] mminit::zonelist thisnode 0:Normal = 0:Normal 0:DMA32 0:DMA [ 0.000000] mminit::zonelist general 1:Normal = 1:Normal 0:Normal 0:DMA32 0:DMA [ 0.000000] mminit::zonelist thisnode 1:Normal = 1:Normal [ 0.000000] Built 2 zonelists, mobility grouping on. Total pages: 8176164 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.17.0-rc6-gfp09+ root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap debug LANG=en_US.UTF-8 mminit_loglevel=4 console=tty0 console=ttyS0,115200n8 memblock=debug earlyprintk=serial,0x3f8,115200 --- Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. The encoding method is XOR. Get zone number from enum zone_type, then encode the number with ZONE_NORMAL by XOR operation. The goal is to make sure ZONE_NORMAL can be encoded to zero. So, the compatibility can be guaranteed, such as GFP_KERNEL and GFP_ATOMIC can be used as before. Reserve __GFP_MOVABLE in bit 3, so that it can continue to be used as a flag. Same as before, __GFP_MOVABLE respresents movable migrate type for ZONE_DMA, ZONE_DMA32, and ZONE_NORMAL. But when it is enabled with __GFP_HIGHMEM, ZONE_MOVABLE shall be returned instead of ZONE_HIGHMEM. __GFP_ZONE_MOVABLE is created to realize it. With this patch, just enabling __GFP_MOVABLE and __GFP_HIGHMEM is not enough to get ZONE_MOVABLE from gfp_zone. All callers should use GFP_HIGHUSER_MOVABLE or __GFP_ZONE_MOVABLE directly to achieve that. Decode zone number directly from bottom three bits of flags in gfp_zone. The theory of encoding and decoding is, A ^ B ^ B = A Changes since v1:[1] * Create __GFP_ZONE_MOVABLE and modify GFP_HIGHUSER_MOVABLE to help callers to get ZONE_MOVABLE. Try to create __GFP_ZONE_MASK to mask lowest 3 bits of GFP bitmasks. * Modify some callers' gfp flag to update usage of address zone modifiers. * Modify inline function gfp_zone to get better performance according to Matthew's suggestion. [1]: https://marc.info/?l=linux-mm&m=152596791931266&w=2 --- Huaisheng Ye (9): include/linux/gfp.h: get rid of GFP_ZONE_TABLE/BAD include/linux/dma-mapping: update usage of zone modifiers drivers/xen/swiotlb-xen: update usage of zone modifiers fs/btrfs/extent_io: update usage of zone modifiers drivers/block/zram/zram_drv: update usage of zone modifiers mm/vmpressure: update usage of zone modifiers mm/zsmalloc: update usage of zone modifiers include/linux/highmem.h: update usage of movableflags arch/x86/include/asm/page.h: update usage of movableflags arch/x86/include/asm/page.h | 3 +- drivers/block/zram/zram_drv.c | 6 +-- drivers/xen/swiotlb-xen.c | 2 +- fs/btrfs/extent_io.c | 2 +- include/linux/dma-mapping.h | 2 +- include/linux/gfp.h | 107 ++++++++---------------------------------- include/linux/highmem.h | 4 +- mm/vmpressure.c | 2 +- mm/zsmalloc.c | 4 +- 9 files changed, 32 insertions(+), 100 deletions(-) -- 1.8.3.1