Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp536727imm; Fri, 8 Jun 2018 00:41:44 -0700 (PDT) X-Google-Smtp-Source: ADUXVKImTQ/QE1oMX/MGTi88tEmP6T15JKpl2jVFpVya/kBjfFSlzWph2oF154udG7ADgjGNP6+c X-Received: by 2002:a63:7d4c:: with SMTP id m12-v6mr4248151pgn.201.1528443704499; Fri, 08 Jun 2018 00:41:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528443704; cv=none; d=google.com; s=arc-20160816; b=QBI3zVMPW/+BWc3a25T8Eyhhq/xWhI5B2ZqcBXkDhSkU9/GxAok90bGa8Fp3RaDp9c mIy3grCHBZW00eHom8e6g4njcqDhjvFQQcf6SAX/a8k1fHoD4QKwlqtw7AKZw+QmtkAS Nexd8yxRd9Ir+mpBEGKA7uZvMDrcxEHVOJ49DuV6bWw8LMCqXNRbeQyW7ehD4NqBeiXT i49Sqwjb6adqpstjb/qfIM6Nor8F1A8raaGTrzchKJZikiTYDxNdpnJTpmybEvW7aGui +wZa+yWj4SzUN8EjBgvzVj4h8RCyVu3jvM2sEDY9YrfE0tBzORqd55d+dqMm8P5qT8RU T3ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=8YYwEQEqUpR8YpJWsv5L1uygFtVzN8khNsEyGb5MDOQ=; b=08bUCcmpIUdomugEHHLKjg4vkfLcv2GLjhANYLmscXDF6j9xGq9G/O8pCOhH+jh7tE ug4pCXiq+4rVNdrh/7nWnu+svfy72bC8tR9EanOfnn2DSrIgOvQ/TRsF9g+5WGJTum4N RPRCFHat4MIspIRRDocKV5YzXu8PAE+OhXv/BUPKdum1gvmI6Ng/i6IQzqmLhwxBc12F fM9EL5pT+GixB6WrzvabmPnxKvydluQA4xAvSgMvy8na4Vg14oc9VrKo2OY5JzcQltql YfsNk0gQyN1048nOvGUdA7uHenGEOsZi3pkuGMF4W5RHWLaNwHT94Pl1m/PUteH6RJEE zEEw== 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 b3-v6si56339485pld.215.2018.06.08.00.41.30; Fri, 08 Jun 2018 00:41:44 -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; 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 S1752349AbeFHHlD (ORCPT + 99 others); Fri, 8 Jun 2018 03:41:03 -0400 Received: from outbound-smtp16.blacknight.com ([46.22.139.233]:37478 "EHLO outbound-smtp16.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751140AbeFHHk7 (ORCPT ); Fri, 8 Jun 2018 03:40:59 -0400 Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp16.blacknight.com (Postfix) with ESMTPS id 32B981C1647 for ; Fri, 8 Jun 2018 08:40:58 +0100 (IST) Received: (qmail 32150 invoked from network); 8 Jun 2018 07:40:58 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[37.228.237.171]) by 81.17.254.9 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Jun 2018 07:40:58 -0000 Date: Fri, 8 Jun 2018 08:40:57 +0100 From: Mel Gorman To: Jirka Hladky Cc: Jakub Racek , linux-kernel , "Rafael J. Wysocki" , Len Brown , linux-acpi@vger.kernel.org Subject: Re: [4.17 regression] Performance drop on kernel-4.17 visible on Stream, Linpack and NAS parallel benchmarks Message-ID: <20180608074057.jtxczsw3jwx6boti@techsingularity.net> References: <20180606122731.GB27707@jra-laptop.brq.redhat.com> <20180607123915.avrqbpp4adgj7ck4@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 08, 2018 at 07:49:37AM +0200, Jirka Hladky wrote: > Hi Mel, > > we will do the bisection today and report the results back. > The most likely outcome is 2c83362734dad8e48ccc0710b5cd2436a0323893 which is a patch that restricts newly forked processes from selecting a remote node when the local node is similarly loaded. The upside is that an almost idle node will not queue that task on a remote node. The downside is that there are cases that the newly forked task allocates a lot of memory and then the idle balancer spreads it anyway. It'll be a classic case of "win some, lose some". That would match this pattern > > > * all processes are started at NODE #1 So at fork time, the local node is almost idle and is used > > > * memory is also allocated on NODE #1 Early in the lifetime of the task > > > * roughly half of the processes are moved to the NODE #0 very quickly. * Idle balancer kicks in > > > however, memory is not moved to NODE #0 and stays allocated on NODE #1 > > > automatic NUMA balancing doesn't run long enough to migrate all the memory. That would definitely be the case for STREAM. It's less clear for NAS where, depending on the parallelisation, wake_affine can keep a task away from its memory or it's cross-node migrating a lot. As before, I've no idea about linpack. -- Mel Gorman SUSE Labs