Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1736856imm; Mon, 3 Sep 2018 08:08:55 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZC2V7xgQxylYFcZ4PHwOVKi4XQ3c950c5ddD6vJNAvMzmJx712lRwptQa7tc8FuW5qyPeW X-Received: by 2002:a63:2150:: with SMTP id s16-v6mr26878212pgm.267.1535987335759; Mon, 03 Sep 2018 08:08:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535987335; cv=none; d=google.com; s=arc-20160816; b=vfI39ZWcLXd6Iwi3xaZQKF9Iydy5kUQRxCg8ZJav1MJqxddqnJCv7G+BWWEKgxZ2tR H0u0cyR0nNWSFm8kZ5YDuPSREilPh9qH30Lb4IAoX635vdH3gsH1e4qjTC/wL0p7Fw6D Yo3BThmLEzLd3robyFu6Y2NpKFkY3P0dxOZM4GvWis7l2fwhjDQi01PI/y2nPm7gOSwZ 5ldXZHUyCpU5iCP+H9cm/mBBvb2HGh1Yww38D6gx/WZ8ISpeqCDvjy9V2hSFryu1wP3t I8lRxIy7nPF+j6ZkZVkj/RUn5yE8sO3q50E53G6dh8DVNerNEDtL+rRlAEGvxGpTRjhp OMUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=XLIqvVqLwDM6Dqkbgodj9J9V+Tclp4D6ftR1elNU8oU=; b=r+Zx9xqVFdxoU4QqKswRMbkHVGi0sHzTfX9QrIgHsR6qGsnLcmlmucVgcWFrVqtWVE cC/dIybMw1lvHxlGmto/XwTXoD4k9So2E954nFNEz5tKyArfKb2aYk3FIw2rpJceQN71 JCjEiOCpDHB+O3L/Bno1jl3mqCs90/u/IdiBVbet/pJCaVPEUnEpXbUuO1R4sAwJs76N Nr6yVb3pSSz0QvQOUzwQq1zStS3XIVb73MrswqHYHG7oO5HttUF5X8xTV6usV3mPDzoi 2G/ZaFlqDcjlla5KkegBJzUHDV3rCBgkhtBSfPbzVQ0fHuDPJwr/kjcTEdZJB8JQuKIG GBWg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h30-v6si18530434pgb.269.2018.09.03.08.08.40; Mon, 03 Sep 2018 08:08:55 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727405AbeICT1w (ORCPT + 99 others); Mon, 3 Sep 2018 15:27:52 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:40653 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726047AbeICT1v (ORCPT ); Mon, 3 Sep 2018 15:27:51 -0400 Received: by mail-oi0-f65.google.com with SMTP id l202-v6so1465289oig.7 for ; Mon, 03 Sep 2018 08:07:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XLIqvVqLwDM6Dqkbgodj9J9V+Tclp4D6ftR1elNU8oU=; b=JQ3Bk+aGG9Nhy0QG+rDBP5Ieb5PNUEMnmLSUO9gV+WwpmjB/E+ikFFdU/5J6s4hrwW ZHhBbnK8Ykp3b9MImOocIaaAHY0Z5aYRVobCU+0cI2n+giOsTI8NEqDedMLqqFs9vMxd dqoL4sSRYgNeWbYdmY+uiYbEdUUghiOMaraSPJhJ+SesbeujlftJUKsAO2Nj/6dqo0dR xZZbxx5TrX3MbE/T2hl50ZlZ2YvxIymLcNbjcpVVH0jmsiwKxqk3bgiiZZzybXlSAGND +CI6UosaahEKT9FQITFHu/PDxm7cDAJyAYnq0rBLgl2df4+WelU5lntG32Ed1CmYogfc 4ZkA== X-Gm-Message-State: APzg51AAh4EKk8uIVw8vIJy5sOneCJxSeRIus/yHMjx/lr5chGsdlpnw ZCpSuOEBfdF5av4D1W1cgqG8zArzU/4RyQSvU54CvQ== X-Received: by 2002:aca:598a:: with SMTP id n132-v6mr20227208oib.158.1535987235947; Mon, 03 Sep 2018 08:07:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:2011:0:0:0:0:0 with HTTP; Mon, 3 Sep 2018 08:07:15 -0700 (PDT) In-Reply-To: References: <20180621092331.p2pmaiu6563kp5u2@techsingularity.net> <20180627084954.73ucqvac62v5gje4@techsingularity.net> <20180717100329.yfy7igdsrpk5ujf4@techsingularity.net> From: Jirka Hladky Date: Mon, 3 Sep 2018 17:07:15 +0200 Message-ID: Subject: Re: [4.17 regression] Performance drop on kernel-4.17 visible on Stream, Linpack and NAS parallel benchmarks To: Mel Gorman Cc: Kamil Kolakowski , Jakub Racek , linux-kernel , "Rafael J. Wysocki" , Len Brown , linux-acpi@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Resending in the plain text mode. > My own testing completed and the results are within expectations and I > saw no red flags. Unfortunately, I consider it unlikely they'll be merged > for 4.18. Srikar Dronamraju's series is likely to need another update > and I would need to rebase my patches on top of that. Given the scope > and complexity, I find it unlikely they would be accepted for an -rc, > particularly this late of an rc. Whether we hit the 4.19 merge window or > not will depend on when Srikar's series gets updated. Hi Mel, we have collaborated back in July on the scheduler patch, improving the performance by allowing faster memory migration. You came up with the "sched-numa-fast-crossnode-v1r12" series here: https://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git which has shown good performance results both in your and our testing. Do you have some update on the latest status? Is there any plan to merge this series into 4.19 kernel? We have just tested 4.19.0-0.rc1.1 and based on the results it seems that the patch is not included (and I don't see it listed in git shortlog v4.18..v4.19-rc1 ./kernel/sched) With 4.19rc1 we see performance drop * up to 40% (NAS bench) relatively to 4.18 + sched-numa-fast-crossnode-v1r12 * up to 20% (NAS, Stream, SPECjbb2005, SPECjvm2008) relatively to 4.18 vanilla The performance is dropping. It's quite unclear what are the next steps - should we wait for "sched-numa-fast-crossnode-v1r12" to be merged or should we start looking at what has caused the drop in performance going from 4.19rc1 to 4.18? We would appreciate any guidance on how to proceed. Thanks a lot! Jirka On Mon, Sep 3, 2018 at 5:04 PM, Jirka Hladky wrote: >> My own testing completed and the results are within expectations and I >> saw no red flags. Unfortunately, I consider it unlikely they'll be merged >> for 4.18. Srikar Dronamraju's series is likely to need another update >> and I would need to rebase my patches on top of that. Given the scope >> and complexity, I find it unlikely they would be accepted for an -rc, >> particularly this late of an rc. Whether we hit the 4.19 merge window or >> not will depend on when Srikar's series gets updated. > > > Hi Mel, > > we have collaborated back in July on the scheduler patch, improving the > performance by allowing faster memory migration. You came up with the > "sched-numa-fast-crossnode-v1r12" series here: > > https://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git > > which has shown good performance results both in your and our testing. > > Do you have some update on the latest status? Is there any plan to merge > this series into 4.19 kernel? We have just tested 4.19.0-0.rc1.1 and based > on the results it seems that the patch is not included (and I don't see it > listed in git shortlog v4.18..v4.19-rc1 ./kernel/sched) > > With 4.19rc1 we see performance drop > > up to 40% (NAS bench) relatively to 4.18 + sched-numa-fast-crossnode-v1r12 > up to 20% (NAS, Stream, SPECjbb2005, SPECjvm2008) relatively to 4.18 vanilla > > The performance is dropping. It's quite unclear what are the next steps - > should we wait for "sched-numa-fast-crossnode-v1r12" to be merged or should > we start looking at what has caused the drop in performance going from > 4.19rc1 to 4.18? > > We would appreciate any guidance on how to proceed. > > Thanks a lot! > Jirka > > > > > On Tue, Jul 17, 2018 at 12:03 PM, Mel Gorman > wrote: >> >> On Tue, Jul 17, 2018 at 10:45:51AM +0200, Jirka Hladky wrote: >> > Hi Mel, >> > >> > we have compared 4.18 + git:// >> > git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git >> > sched-numa-fast-crossnode-v1r12 against 4.16 kernel and performance >> > results >> > look very good! >> > >> >> Excellent, thanks to both Kamil and yourself for collecting the data. >> It's helpful to have independent verification. >> >> > We see performance gains about 10-20% for SPECjbb2005. NAS results are a >> > little bit noisy but show overall performance gains as well (total >> > runtime >> > for reduced from 6 hours 34 minutes to 6 hours 26 minutes to give you a >> > specific example). >> >> Great. >> >> > The only benchmark showing a slight regression is stream >> > - but the regression is just a few percents ( upto 10%) and I think it's >> > not a real concern given that it's an artificial benchmark. >> > >> >> Agreed. >> >> > How is your testing going? Do you think >> > that sched-numa-fast-crossnode-v1r12 series can make it into the 4.18? >> > >> >> My own testing completed and the results are within expectations and I >> saw no red flags. Unfortunately, I consider it unlikely they'll be merged >> for 4.18. Srikar Dronamraju's series is likely to need another update >> and I would need to rebase my patches on top of that. Given the scope >> and complexity, I find it unlikely they would be accepted for an -rc, >> particularly this late of an rc. Whether we hit the 4.19 merge window or >> not will depend on when Srikar's series gets updated. >> >> > Thanks a lot for your efforts to improve the performance! >> >> My pleasure. >> >> -- >> Mel Gorman >> SUSE Labs > >