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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 01 Jul 2013 10:15:16 +0200
From:	Lukasz Majewski <l.majewski@...sung.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocky" <rjw@...k.pl>
Cc:	Lukasz Majewski <l.majewski@...sung.com>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Jonghwa Lee <jonghwa3.lee@...sung.com>,
	Myungjoo Ham <myungjoo.ham@...sung.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Lukasz Majewski <l.majewski@...ess.pl>,
	Andre Przywara <andre.przywara@...aro.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <eduardo.valentin@...com>
Subject: Re: [PATCH v4 5/7] cpufreq: Calculate number of busy CPUs

On Fri, 28 Jun 2013 08:54:57 +0200, Lukasz Majewski wrote:
> > > So thermal or "other solution" [*] shall disable boost when
> > > overheated and enable it back when things cool down.  
> > 
> > yeah..  
> 
> For me thermal is a good candidate to enable boost again. I only need
> to find a proper place for it.

Unfortunately, after careful investigation it turned out, that thermal
is suited to disable boost when overheating is detected. (since it uses
thermal subsystem interrupt to take action).

The problem is with enabling boost again, since thermal (at least at my
board) only reacts on TMU (thermal) interrupt. Thermal thread may be
started, but I don't regard this as a good solution (to extra bloat
thermal).

> 
> >   
> > > [*] @ Viresh & Rafael do you have any idea about the "other
> > > solution" here?  
> > 
> > Not really sure :)  
> 
> Not any single one? Then I would like to propose thermal.
> 

Does anybody have any idea here? As written above, thermal is suitable
to disable boost.

I'd like to bring those three options under discussion:

1. boost attr is always exported -> do not enable boost automatically
   when disabled by thermal (as it was proposed at v4).

2. boost attr is always exported -> find a way to enable boost after
   emergency disablement when thermal detects overheating (newest
   proposition). 

3. boost attr only exported at x86 (when supported)
   boost attr NOT exported via sysfs for SW controlled boost (e.g.
   Exynos ARM).

   Then we only enable/disable boost at kernel and don't need to take
   care of the user space interaction. This scenario is my use case. I
   hadn't planned to expose boost to userspace and use it with LAB as a
   kernel API.


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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/

Powered by blists - more mailing lists