linux-kernel - Re: [RFC] maximum latency tracking infrastructure

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]

Message-ID: <p73r6z5erbw.fsf@verdi.suse.de>
Date:	24 Aug 2006 23:50:27 +0200
From:	Andi Kleen <ak@...e.de>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	linux-kernel@...r.kernel.org, len.brown@...el.com
Subject: Re: [RFC] maximum latency tracking infrastructure

Jesse Barnes <jbarnes@...tuousgeek.org> writes:

> On Thursday, August 24, 2006 2:20 pm, Arjan van de Ven wrote:
> > Jesse Barnes wrote:
> > > On Thursday, August 24, 2006 10:41 am, Arjan van de Ven wrote:
> > >> The reason for adding this infrastructure is that power management
> > >> in the idle loop needs to make a tradeoff between latency and power
> > >> savings (deeper power save modes have a longer latency to running
> > >> code again).
> > >
> > > What if a processor was already in a sleep state when a call to
> > > set_acceptable_latency() latency occurs?
> >
> > there's nothing sane that can be done in that case; any wake up
> > already will cause the unwanted latency! A premature wakeup is only
> > making it happen *now*, but now is as inconvenient a time as any...
> > (in fact it may be a worst case time scenario, say, an audio
> > interrupt...)
> 
> Depends on what's going on.  What if you have a two socket machine, and 
> one CPU is in C3 when the latency setting occurs?

I didn't think there were currently any multi socket machines with C3 
support? The best you get is dual core.

> Shouldn't you wake it 
> up and prevent it from going that deep again?  But you're right, you 
> won't necessarily improve anything...

Generally there are so many events that wake up CPUs that the case is pretty 
academic -- all CPUs will eventually wake up in a reasonable time
(before your driver initialization finished likely) and then follow
the new latency settings.

Maybe at some point if all the idle breaking events in Linux have been
fixed up it might be a problem, but I think that's a long time off.

-Andi

-
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/