Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5947632ybe; Tue, 17 Sep 2019 16:40:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxQOubmRdI/5PmgrLaTQpawnbCLXolN1DnxPzTFcadfs1SFWUdmU5E25szW4T4Dz1JPmXtD X-Received: by 2002:a50:ee08:: with SMTP id g8mr7348322eds.261.1568763611086; Tue, 17 Sep 2019 16:40:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568763611; cv=none; d=google.com; s=arc-20160816; b=FfpqIWI/ZKHQNE3GM9KYyQUpUmzwhFHFW3pVd6W82dB4WfmCi7unlfqA4m3uU8sO7G OwGXxLB2S+i1LrCk7pUdUhXGRvWXUpIxxMVHTlMMzMsQLJgZtQtuDL4Ni/CoEYVO7NNo uPpObecPGUwQHg7XttvYIA9Fg7TcSkFpegXlkzVk7GJXHtJO6N/nnLIzRcLwqsLSZKte xjacNVQjhmthGBmqPiB1mkJ/yud3uNDxCdoGjAE2E/VM9WPDjYccAize1zyGmxZTrSa3 OzyZCuOeRID5b9Oa4sZiI+bwluscfy9/jIA426dNxLsLY1ysI/I+CsP6XVIcgcyKC1Jp Vv6A== 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:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=FpEZp0qngUYKmorgXSBFusDtFDiiCFt79lAr1iVP3dA=; b=h6qOyzsLUgl2akOIE26X2KAGsHCJHXhMQe+xGiyDyGgLVonvvZDA+dVHRZdoaZ94Ts PGIOEE55rCsSgKrQQ8aShhR3vdCK2m1dnkAgsuPpGOQ7uWp3KO4/8GK7xBJRdb1GRHNs YClQsh/rH+pk1FkyTDD1aOPnF4h3Pk78CPcbgcKQLSQp9146P+cQ6EiDRzZO+GIbNBQk QBMUrgEPM+23FR8kwd5Sv0HDrel37ba64daPS5Rh6V97c4/EqoE3mVApOfpQjhZNJ6Tb q98FtdChfoOOQ13C5nCK3OqWxzqPFEGoey8Q8ThRst95bFc3NywNy2s/fAr8YjlNxM69 uLiA== 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 e10si1967608ejf.69.2019.09.17.16.39.48; Tue, 17 Sep 2019 16:40:11 -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 S1727743AbfIQOWZ (ORCPT + 99 others); Tue, 17 Sep 2019 10:22:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:50946 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725922AbfIQOWZ (ORCPT ); Tue, 17 Sep 2019 10:22:25 -0400 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 A8884B6D9; Tue, 17 Sep 2019 14:22:23 +0000 (UTC) Message-ID: <1568730466.3329.4.camel@suse.cz> Subject: Re: [PATCH 1/2] x86,sched: Add support for frequency invariance From: Giovanni Gherdovich To: Quentin Perret Cc: srinivas.pandruvada@linux.intel.com, tglx@linutronix.de, mingo@redhat.com, peterz@infradead.org, bp@suse.de, lenb@kernel.org, rjw@rjwysocki.net, x86@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, mgorman@techsingularity.net, matt@codeblueprint.co.uk, viresh.kumar@linaro.org, juri.lelli@redhat.com, pjt@google.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com Date: Tue, 17 Sep 2019 16:27:46 +0200 In-Reply-To: <20190914105708.GA12877@qperret.net> References: <20190909024216.5942-1-ggherdovich@suse.cz> <20190909024216.5942-2-ggherdovich@suse.cz> <20190914105708.GA12877@qperret.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Quentin, On Sat, 2019-09-14 at 12:57 +0200, Quentin Perret wrote: > Hi Giovanni > > On Monday 09 Sep 2019 at 04:42:15 (+0200), Giovanni Gherdovich wrote: > > +static inline long arch_scale_freq_capacity(int cpu) > > +{ > > + if (static_cpu_has(X86_FEATURE_APERFMPERF)) > > + return per_cpu(arch_cpu_freq, cpu); > > So, if this is conditional, perhaps you could also add this check in an > x86-specific implementation of arch_scale_freq_invariant() ? That would > guide sugov in the right path (see get_next_freq()) if APERF/MPERF are > unavailable. > > > + return 1024 /* SCHED_CAPACITY_SCALE */; > > +} > Good remark. If the cpu doesn't have APERF/MPERF, the choice here is that freq_curr is constantly equal to freq_max, and the scaling factor is 1 all the time. But I'm checking this static_cpu_has() every time I do a frequency update; arguably schedutil should be smarter and settle such a case once and for all at boot time. I'll check what's the cost of static_cpu_has() and if it's non-negligible I'll do what you suggest (x86-specific version of arch_scale_freq_invariant(). Giovanni