linux-kernel - Re: [PATCH] thermal/intel_powerclamp: convert to smpboot thread

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] [day] [month] [year] [list]

Date:	Wed, 13 Apr 2016 07:20:36 -0700
From:	Jacob Pan <jacob.jun.pan@...ux.intel.com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	linux-kernel@...r.kernel.org, rt@...utronix.de,
	Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <edubezval@...il.com>,
	linux-pm@...r.kernel.org,
	"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
	Petr Mladek <pmladek@...e.com>, jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH] thermal/intel_powerclamp: convert to smpboot thread

On Mon, 11 Apr 2016 18:04:37 +0200
Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:

> If you raise_softirq() then softirqs are run on return from IRQ code.
> If raise them while holding a BH lock then then they are run after you
> drop the BH lock / enable BH again.
> If the softirq processing is deferred to ksoftirqd *then* you see the
> pending bits.
> 
you are right. there is no need to check in the thread context. the
forced idle only yield to softirqs that are not in ksoftirqd.
thanks for pointing it out. i will remove it.
> >>>> The timer is probably here if mwait would let it sleep too long.
> >>>>  
> >>> not sure i understand. could you explain?  
> >>
> >> The timer invokes noop_timer() which does nothing so the only thing
> >> you want is the interrupt. Your mwait_idle_with_hints() could let
> >> you sleep say for one second. But the timer ensures that you wake
> >> up no later than 100us.
> >>  
> > yeah, that is the idea to make sure we don't oversleep. You mean we
> > can optimize this but avoid extra wake ups? e.g. cancel timer if we
> > already sleep enough time?  
> 
> No, just stated / summarized what I *assumed* the timer was doing and
> just confirmed it.
> I don't see a way how you can cancel the timer.
i don't either, you have to wake up first to cancel.
> And that is why I
> suggest to run as an idle handler because those can sleep endless :)
can you be more specific about idle handler? and we don't want to sleep
more than user required length since the goal is to  get all cpus sleep
and wake up the same time to maximize the overlapped idle states.
> But since you have RT priority you need to make sure that a process
> with lower priority manages to get on the CPU at some point.