linux-kernel - Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4899012.FZHBNtJbTr@vostro.rjw.lan>
Date:	Mon, 03 Jun 2013 12:32:36 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Stratos Karafotis <stratosk@...aphore.gr>,
	linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency

On Monday, June 03, 2013 12:21:47 PM Viresh Kumar wrote:
> On 2 June 2013 01:07, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote:
> 
> >> Even removal of __cpufreq_driver_getavg() should be done in a separate
> >> patch, so that it can be reverted easily if required later.
> >
> > Why would you want to revert it separately?
> 
> We might not need to revert all the changes that Stratos is doing.
> Only a revert of getavg() and its users + a small fix in governor would
> be enough. Stratos patch isn't only about removing getavg() but how
> ondemand works and so breaking stuff might be more useful.

Yes, it's probably better to do the getavg() removal as a separate patch.

> >> >> "Proportional to load" means C * load, so why is "policy->max / 100" *the* right C?
> >> >
> >> > I think, finally(?) I see your point. The right C should be "policy->cpuinfo.max_freq / 100".
> >>
> >> Why are you changing it to cpuinfo.max_freq?? This is fixed once a driver is
> >> initialized.. but user may request a lower max freq for a governor or policy.
> >> Which is actually reflected in policy->max I believe.
> >
> > Which doesn't matter.  The formula should provide the same results regardless
> > of the user settings except that the selected frequency should be capped by
> > policy->max (instead of being proportional to it).  I think using
> > cpuinfo.max_freq here is correct.
> 
> I am confused now about what to use.. This is how I read it:
> 
> Assumption: CPU supports following freq range.. 500 MHz, 600 MHz, 700 MHz,
> 800 MHz, 900 MHz, 1 GHz
> 
> cpuinfo.max_freq = 1 GHz
> policy->max is set to 600 MHz
> 
> Case 1: Use policy->max:
> 
> We need load to be over 500/600 (i.e. .834) to move to 600 MHz.
> 
> Case 2: Use cpuinfo.max_freq..
> 
> We need load to be over 500/1000 (i.e. .5) to move to 600 MHz.
> 
> So, obviously the calculations aren't the same..

No, they aren't.

My point is that the set of frequencies to choose from doesn't change with
the changes of user settings, so the computation should use things that
don't with the user settings either.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/