Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7223155imu; Thu, 31 Jan 2019 06:59:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN4EOp2LreiOignFSlUv0DTIzwmvX/sd+up6sEurb6Dfj97uAWefa2/1qkaRHW/2SqgiqOXk X-Received: by 2002:a62:18ce:: with SMTP id 197mr36297530pfy.88.1548946780976; Thu, 31 Jan 2019 06:59:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548946780; cv=none; d=google.com; s=arc-20160816; b=dsuAWHTqSCUnpzXKf1N93XhGKUvdhCgOlXl4QGFuTIkCdZTm4e9T47q+ykcPk6uCnz 74Uts9C2O7wjPWV11JJpiIYwhYlVQpnaSBDhdrGyqnZd6ltkgXy2e5NrpLWc2wPJkONJ Ow51mSGQV6FUnts12IqYLsPFXn7pCZ2oN5HPr/PkZV+IkPwpp0qdXT+mbQx+3Tyq8YjK ipPCHsulnEFW4Gp2dAeU6xd1tuaKzcmc5Raf2bHrpiZZq+KFPAO7wjWDumLu1SYSegtA nx8aNT7lZ7Z6ECbWh6WuEdzwJ1YqpOmnzqCWXLrimo25IJSuLPgS7QPklpZehDrfle6v BZUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:openpgp:from:references:cc:to:subject; bh=PB/ZhEE/njpeWywvK5pPhRT9RGHOmRWGcvYMiiFnw2Q=; b=MzDu42KTL9RnRUMtvdBml+ymbKHuFux7V7i+a8I5yh/9cf3cfJ25rayWmIFUs1iLOy OPeGMgSWSi2fLxi7788OjBVcYHfWDknFK3kcEig2XtQR0EVIhV88Me3IxFg0qWDDNbjX hhhEX5gDZ5R0ZLgcaMa8s0NfW0vvvbqLXMPo+7j2tFYggxK4fOBS8SVjwqku4tcpAM5O FWKDYrnCexRc1bcZHD2b7DH3dA8VQUj9tzCdKAcl96s7k6oCNoOxMZsN2ts7F157dx69 V/isv3lKdMFUbS9ahZJdKAh1mCl3dyrw44c5IXwjR9vf81GNWMc9g2s84uGcL8jhaZjK qklw== 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 g12si4710444pll.428.2019.01.31.06.59.26; Thu, 31 Jan 2019 06:59:40 -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 S1731632AbfAaOwN (ORCPT + 99 others); Thu, 31 Jan 2019 09:52:13 -0500 Received: from mx2.suse.de ([195.135.220.15]:39552 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725796AbfAaOwN (ORCPT ); Thu, 31 Jan 2019 09:52:13 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3A6BEAD14; Thu, 31 Jan 2019 14:52:11 +0000 (UTC) Subject: Re: [PATCH 11/22] mm, compaction: Use free lists to quickly locate a migration target To: Mel Gorman , Andrew Morton Cc: David Rientjes , Andrea Arcangeli , Linux List Kernel Mailing , Linux-MM References: <20190118175136.31341-1-mgorman@techsingularity.net> <20190118175136.31341-12-mgorman@techsingularity.net> From: Vlastimil Babka Openpgp: preference=signencrypt Message-ID: <81e45dc0-c107-015b-e167-19d7ca4b6374@suse.cz> Date: Thu, 31 Jan 2019 15:52:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190118175136.31341-12-mgorman@techsingularity.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/18/19 6:51 PM, Mel Gorman wrote: > Similar to the migration scanner, this patch uses the free lists to quickly > locate a migration target. The search is different in that lower orders > will be searched for a suitable high PFN if necessary but the search > is still bound. This is justified on the grounds that the free scanner > typically scans linearly much more than the migration scanner. > > If a free page is found, it is isolated and compaction continues if enough > pages were isolated. For SYNC* scanning, the full pageblock is scanned > for any remaining free pages so that is can be marked for skipping in > the near future. > > 1-socket thpfioscale > 5.0.0-rc1 5.0.0-rc1 > isolmig-v3r15 findfree-v3r16 > Amean fault-both-3 3024.41 ( 0.00%) 3200.68 ( -5.83%) > Amean fault-both-5 4749.30 ( 0.00%) 4847.75 ( -2.07%) > Amean fault-both-7 6454.95 ( 0.00%) 6658.92 ( -3.16%) > Amean fault-both-12 10324.83 ( 0.00%) 11077.62 ( -7.29%) > Amean fault-both-18 12896.82 ( 0.00%) 12403.97 ( 3.82%) > Amean fault-both-24 13470.60 ( 0.00%) 15607.10 * -15.86%* > Amean fault-both-30 17143.99 ( 0.00%) 18752.27 ( -9.38%) > Amean fault-both-32 17743.91 ( 0.00%) 21207.54 * -19.52%* > > The impact on latency is variable but the search is optimistic and > sensitive to the exact system state. Success rates are similar but > the major impact is to the rate of scanning > > 5.0.0-rc1 5.0.0-rc1 > isolmig-v3r15 findfree-v3r16 > Compaction migrate scanned 25646769 29507205 > Compaction free scanned 201558184 100359571 > > The free scan rates are reduced by 50%. The 2-socket reductions for the > free scanner are more dramatic which is a likely reflection that the > machine has more memory. > > [dan.carpenter@oracle.com: Fix static checker warning] > [vbabka@suse.cz: Correct number of pages scanned for lower orders] > Signed-off-by: Mel Gorman Acked-by: Vlastimil Babka Small fix below: > -/* Reorder the free list to reduce repeated future searches */ > +/* > + * Used when scanning for a suitable migration target which scans freelists > + * in reverse. Reorders the list such as the unscanned pages are scanned > + * first on the next iteration of the free scanner > + */ > +static void > +move_freelist_head(struct list_head *freelist, struct page *freepage) > +{ > + LIST_HEAD(sublist); > + > + if (!list_is_last(freelist, &freepage->lru)) { Shouldn't there be list_is_first() for symmetry? > + list_cut_before(&sublist, freelist, &freepage->lru); > + if (!list_empty(&sublist)) > + list_splice_tail(&sublist, freelist); > + } > +} > + > +/* > + * Similar to move_freelist_head except used by the migration scanner > + * when scanning forward. It's possible for these list operations to > + * move against each other if they search the free list exactly in > + * lockstep. > + */ > static void > move_freelist_tail(struct list_head *freelist, struct page *freepage) > {