Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3410926imu; Fri, 18 Jan 2019 09:54:04 -0800 (PST) X-Google-Smtp-Source: ALg8bN6QXBelXrqkgJzDWbfPKMRHg4MC2pJ8aH4xTkA39wQVU9+aiMAMyS7+bTJe+Soj1UrENMuS X-Received: by 2002:a63:5922:: with SMTP id n34mr18569634pgb.435.1547834044188; Fri, 18 Jan 2019 09:54:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547834044; cv=none; d=google.com; s=arc-20160816; b=TYzjy+7jAsWFJjtaKDVhOmgcbPGteEdrH4gpRALepza7o+qX9tUg/aa/eQ8Rc6z22o O4tMGUQyUr0WhqvWk5MYYzRCM3cctvGZDtpBVZEIiK8kFdZbMBYzEX/oDqvPaGsCavxT j1FaXa3zHedxF/A4LEAK92YT3yX9nMPz+5nZtUAyFj7Z2GzO0n4mANtVf1LQhb5e/rnH q1vtG6RXv1ehTTuDxZwOkg1WYGJZYBGrWQwUSOK1pgLmf/tbLRIvH9q90HuFuJi5wtoF RL2N1jxKarZoJDlkHjxM5i8tKKArIzEoFSxZmw3piLCjpubNdaipxGZD8Tq246qNVYMK mhCg== 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; bh=HykaP6BM1ZrAzK3xANMgLCkwNoiAHaQBPyZbtcAqtIs=; b=ewmzfty6C6J5dNt+1IYbzQ63sWov+3fJwpsrMO+nw/H7UcAaa8MCorH8VlDJNR8c9R eiUbyAp+aS+28OENtKxoWua1DbLc168HmEJhX6m2EfFUUMDO3ahK5+5E9TCULPOsqTlm fPuVjrJfOOu12C0gjHe+PssbE/YJyEmDmDYa6HHeObA1HScJL4dTIcwkNdqIOemdII+S C1KnxsUd6AWhX3boT95TnkuJUaQvpwNGwdbNfXNCxPX067gp2wJBOG8cb87XkUQqnfLq 6RBYuwH1QbD9CgXZovY+9OszHdvoXiMEpNS4EJOUqaidIQJi9FL6k23LSD6oSR09gq78 k4zQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si5271298pld.197.2019.01.18.09.53.44; Fri, 18 Jan 2019 09:54:04 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728576AbfARRvv (ORCPT + 99 others); Fri, 18 Jan 2019 12:51:51 -0500 Received: from outbound-smtp13.blacknight.com ([46.22.139.230]:45468 "EHLO outbound-smtp13.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727940AbfARRvv (ORCPT ); Fri, 18 Jan 2019 12:51:51 -0500 Received: from mail.blacknight.com (unknown [81.17.254.16]) by outbound-smtp13.blacknight.com (Postfix) with ESMTPS id 2B2331C3568 for ; Fri, 18 Jan 2019 17:51:47 +0000 (GMT) Received: (qmail 30217 invoked from network); 18 Jan 2019 17:51:47 -0000 Received: from unknown (HELO stampy.163woodhaven.lan) (mgorman@techsingularity.net@[37.228.229.96]) by 81.17.254.9 with ESMTPA; 18 Jan 2019 17:51:47 -0000 From: Mel Gorman To: Andrew Morton Cc: David Rientjes , Andrea Arcangeli , Vlastimil Babka , Linux List Kernel Mailing , Linux-MM , Mel Gorman Subject: [PATCH 00/22] Increase success rates and reduce latency of compaction v3 Date: Fri, 18 Jan 2019 17:51:14 +0000 Message-Id: <20190118175136.31341-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.16.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a drop-in replacement for the series currently in Andrews tree that incorporates static checking and compile warning fixes (Dan, YueHaibing) and extensive review feedback from Vlastimil. Big thanks to Vlastimil as the review was extremely detailed and a number of issues were caught. Not all the patches have been acked but I think an update is still worthwhile. Andrew, please drop the series you have and replace it with the following on the off-chance we get bug reports that are fixed already. Doing this with -fix patches would be relatively painful for little gain. Changelog since v2 o Fix static checker warnings (dan) o Fix unused variable warnings (yue) o Drop patch about PageReserved as there is some abuse of the flag outside of the mm core. (vbabka) o Drop patch using the bulk free helper as it may be vulnerable to races with compaction and gup (vbabka) o Drop patch about remote compaction. It's unnecessary at this time and unclear what the semantics should even be (vbabka) o Changelog fixes and clarifications (vbabka) o Free list management and search Confined mostly to "mm, compaction: Use free lists to quickly locate a migration source" which is arguably the most heavily modified patch in this revision (vbabka, mel) o Some minor churn, modifications, flow changes that fallout from addressing the review feedback (mel) o Minor pageblock skip changes, mostly fixing up which patch makes the changes so the patches are incremental (mel) This series reduces scan rates and success rates of compaction, primarily by using the free lists to shorten scans, better controlling of skip information and whether multiple scanners can target the same block and capturing pageblocks before being stolen by parallel requests. The series is based on mmotm from January 9th, 2019 with the previous compaction series reverted. I'm mostly using thpscale to measure the impact of the series. The benchmark creates a large file, maps it, faults it, punches holes in the mapping so that the virtual address space is fragmented and then tries to allocate THP. It re-executes for different numbers of threads. From a fragmentation perspective, the workload is relatively benign but it does stress compaction. The overall impact on latencies for a 1-socket machine is baseline patches Amean fault-both-3 3832.09 ( 0.00%) 2748.56 * 28.28%* Amean fault-both-5 4933.06 ( 0.00%) 4255.52 ( 13.73%) Amean fault-both-7 7017.75 ( 0.00%) 6586.93 ( 6.14%) Amean fault-both-12 11610.51 ( 0.00%) 9162.34 * 21.09%* Amean fault-both-18 17055.85 ( 0.00%) 11530.06 * 32.40%* Amean fault-both-24 19306.27 ( 0.00%) 17956.13 ( 6.99%) Amean fault-both-30 22516.49 ( 0.00%) 15686.47 * 30.33%* Amean fault-both-32 23442.93 ( 0.00%) 16564.83 * 29.34%* The allocation success rates are much improved baseline patches Percentage huge-3 85.99 ( 0.00%) 97.96 ( 13.92%) Percentage huge-5 88.27 ( 0.00%) 96.87 ( 9.74%) Percentage huge-7 85.87 ( 0.00%) 94.53 ( 10.09%) Percentage huge-12 82.38 ( 0.00%) 98.44 ( 19.49%) Percentage huge-18 83.29 ( 0.00%) 99.14 ( 19.04%) Percentage huge-24 81.41 ( 0.00%) 97.35 ( 19.57%) Percentage huge-30 80.98 ( 0.00%) 98.05 ( 21.08%) Percentage huge-32 80.53 ( 0.00%) 97.06 ( 20.53%) That's a nearly perfect allocation success rate. The biggest impact is on the scan rates Compaction migrate scanned 55893379 19341254 Compaction free scanned 474739990 11903963 The number of pages scanned for migration was reduced by 65% and the free scanner was reduced by 97.5%. So much less work in exchange for lower latency and better success rates. The series was also evaluated using a workload that heavily fragments memory but the benefits there are also significant, albeit not presented. It was commented that we should be rethinking scanning entirely and to a large extent I agree. However, to achieve that you need a lot of this series in place first so it's best to make the linear scanners as best as possible before ripping them out. include/linux/compaction.h | 3 +- include/linux/mmzone.h | 2 + include/linux/sched.h | 4 + kernel/sched/core.c | 3 + mm/compaction.c | 1000 ++++++++++++++++++++++++++++++++++---------- mm/internal.h | 23 +- mm/migrate.c | 2 +- mm/page_alloc.c | 76 +++- 8 files changed, 888 insertions(+), 225 deletions(-) -- 2.16.4