From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E3F4C04EB9 for ; Mon, 3 Dec 2018 18:30:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5DD9E208A3 for ; Mon, 3 Dec 2018 18:30:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DD9E208A3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726745AbeLCSa4 (ORCPT ); Mon, 3 Dec 2018 13:30:56 -0500 Received: from mx2.suse.de ([195.135.220.15]:43630 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726365AbeLCSaz (ORCPT ); Mon, 3 Dec 2018 13:30:55 -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 2CCA1B025; Mon, 3 Dec 2018 18:30:52 +0000 (UTC) Date: Mon, 3 Dec 2018 19:30:50 +0100 From: Michal Hocko To: Linus Torvalds Cc: ying.huang@intel.com, Andrea Arcangeli , s.priebe@profihost.ag, mgorman@techsingularity.net, Linux List Kernel Mailing , alex.williamson@redhat.com, lkp@01.org, David Rientjes , kirill@shutemov.name, Andrew Morton , zi.yan@cs.rutgers.edu, Vlastimil Babka Subject: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression Message-ID: <20181203183050.GL31738@dhcp22.suse.cz> References: <20181127062503.GH6163@shao2-debian> <20181127205737.GI16136@redhat.com> <87tvk1yjkp.fsf@yhuang-dev.intel.com> <20181203181456.GK31738@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 03-12-18 10:19:55, Linus Torvalds wrote: > On Mon, Dec 3, 2018 at 10:15 AM Michal Hocko wrote: > > > > The thing is that there is no universal win here. There are two > > different types of workloads and we cannot satisfy both. > > Ok, if that's the case, then I'll just revert the commit. > > Michal, our rules are very simple: we don't generate regressions. It's > better to have old reliable behavior than to start creating *new* > problems. I do not get it. 5265047ac301 which this patch effectively reverts has regressed kvm workloads. People started to notice only later because they were not running on kernels with that commit until later. We have 4.4 based kernels reports. What do you propose to do for those people? Let me remind that it was David who introduced 5265047ac301, presumably because his workload benefits from it. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8115252952468819458==" MIME-Version: 1.0 From: Michal Hocko To: lkp@lists.01.org Subject: Re: [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression Date: Mon, 03 Dec 2018 19:30:50 +0100 Message-ID: <20181203183050.GL31738@dhcp22.suse.cz> In-Reply-To: List-Id: --===============8115252952468819458== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon 03-12-18 10:19:55, Linus Torvalds wrote: > On Mon, Dec 3, 2018 at 10:15 AM Michal Hocko wrote: > > > > The thing is that there is no universal win here. There are two > > different types of workloads and we cannot satisfy both. > = > Ok, if that's the case, then I'll just revert the commit. > = > Michal, our rules are very simple: we don't generate regressions. It's > better to have old reliable behavior than to start creating *new* > problems. I do not get it. 5265047ac301 which this patch effectively reverts has regressed kvm workloads. People started to notice only later because they were not running on kernels with that commit until later. We have 4.4 based kernels reports. What do you propose to do for those people? Let me remind that it was David who introduced 5265047ac301, presumably because his workload benefits from it. -- = Michal Hocko SUSE Labs --===============8115252952468819458==--