Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3285826imm; Tue, 17 Jul 2018 02:06:51 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcaksCJNqwIMceG7koJfh1Y5+KnU4v/X36sWu6E3l3GFO6m897y9ly73ruK00TOEzGILaio X-Received: by 2002:a63:6986:: with SMTP id e128-v6mr773855pgc.294.1531818411868; Tue, 17 Jul 2018 02:06:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531818411; cv=none; d=google.com; s=arc-20160816; b=KRxTNkfr4Ni8AoivwtdXV4FBHRdG5gBjHybrxSk0efPMs/h3uOspIiI5J2hFZ74lE3 RReYoHY57o5vNSX2aX11r1fDq0AjC6PJ4tKAdT+lz6a7wJw0vhOCn6pWm6eo7uLxHB0z daacgTM5CTIOKKfAi+TfeKh5Q2xQB/m125wMw3QlahNN5N9VqmJqoOyCZ6vrlTKLd8LX dn4fga8AfdaV/IraHTQ/UGHOlTKV2IsCb63wEqbnih5qx+u8QHkAZpDoSxUJvDQHgL1A C4g4pZFZeHHIan8sQFpiLJN0s+z3MzAo6O/4EUyNhxdvrzjF6K7PrckPNHWig7BsBu7t JNvA== 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=UgqAMUs7Uom2sTFe/3F8WXPVjcnsKwNNRGyj4hMNFo4=; b=KJ+fd9rzQLQIOgBzHjZYTXbzTriyUZla7JlUK5zP2CXeiAEeeHWAYm74o0ZLz2ki2l SsV273UcUhc9Hd+XZvPCfgeGu45xin2qatz/yt88fEQGN+SVKGHBE9arBnZO3dS2R+QU LzClku28IGKnTt3JyDT4NUrvzsPSkcVHURLqpBuxvPXoQZnOu8t+tUssPFnir3HQ6pzM e1TaelWFl+JMpphw41MFoIgqZuU+pXkNAF7W+gUgs87sqrpMiwW5kzINCodlO7HCUBAh B9aC4bvNK0XEkx7tui2u0X+2NvroDb6D4HrP1KICKtdGFck03XWVo4yZ0bMQoK6/GbvD 3PUg== 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 e96-v6si421349plb.447.2018.07.17.02.06.36; Tue, 17 Jul 2018 02:06:51 -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 S1729631AbeGQJhe (ORCPT + 99 others); Tue, 17 Jul 2018 05:37:34 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:55746 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728340AbeGQJhe (ORCPT ); Tue, 17 Jul 2018 05:37:34 -0400 Received: from emea4-mta.ukb.novell.com ([10.120.13.87]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Tue, 17 Jul 2018 11:05:56 +0200 Received: from suselix (nwb-a10-snat.microfocus.com [10.120.13.201]) by emea4-mta.ukb.novell.com with ESMTP (TLS encrypted); Tue, 17 Jul 2018 10:05:51 +0100 Date: Tue, 17 Jul 2018 11:05:49 +0200 From: Andreas Herrmann To: Peter Zijlstra Cc: "Rafael J. Wysocki" , Frederic Weisbecker , Viresh Kumar , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Commit 554c8aa8ecad causing severe performance degression with pcc-cpufreq Message-ID: <20180717090549.pbhpua443yqguyhy@suselix> References: <20180717065048.74mmgk4t5utjaa6a@suselix> <20180717081507.GS2476@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180717081507.GS2476@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 17, 2018 at 10:15:07AM +0200, Peter Zijlstra wrote: > On Tue, Jul 17, 2018 at 08:50:48AM +0200, Andreas Herrmann wrote: > > I've recently noticed that commit 554c8aa8ecad ("sched: idle: Select > > idle state before stopping the tick") causes severe performance drop > > for systems using pcc-cpufreq driver. Depending on the number of CPUs > > the system might be almost unusable. > > Have you looked at that driver? It features a global lock which is taken > for all cpufreq operations. Once you get past a handful of cpus that > will constrict your system exactly as you say. Yes, I figured that already and you better use another cpufreq driver on those systems. (But that such systems with this driver are almost unusable is a new feature ;-) > What kind of machine are you running this on, and can you configure the > thing to use anything else? Its an older system. HP ProLiant DL580 Gen8, CPUs are Intel(R) Xeon(R) CPU E7-4890 4 nodes, With HT enabled 120 logical CPUs. Yes you can configure it using something else. For the record. On this and similar systems pcc-cpufreq driver is used when BIOS setting for power management option "Power Regulator" is set to "Dynamic Power Savings Mode" AFAIK this is the default setting for this option. When changing this setting to "OS Control Mode" intel_pstate driver should be loaded. > If so, do so and never look back. Ok, I am fine with this. Thanks, Andreas