linux-kernel - Re: Attempted summary of suspend-blockers LKML 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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 1 Aug 2010 12:27:08 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Mikael Abrahamsson <swmike@....pp.se>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Sun, Aug 01, 2010 at 08:49:43AM +0200, Mikael Abrahamsson wrote:
> On Sun, 1 Aug 2010, Mikael Abrahamsson wrote:
> 
> >it's just that mobile (low power) wasn't the intended target of
> >the application when it was written, and this commonly shows.

Good points in both this and your earlier post!!!

> I have another aspect I just thought about. I work for a telephony
> company. We provide Internet connectivity throught various means,
> DSL, Ethernet to the Home, mobile etc.
> 
> For ETTH and DSL, network usage is pretty straight forward, you send
> packets, they get delivered pretty quickly with low marginal cost
> per packet. For mobile, this is not quite so simple. Mobile networks
> are designed for terminal/UE (user equipment) to use low power, so
> they go down in low power state after a while. Let's take the case
> of 3G/HSPA:
> 
> After a short while (second) of idleness (no packets being sent),
> the mobile network negotiates away the high speed resources (the one
> that enables multimegabit/s transfers) and tries to give it to
> someone else. After approximately 30 seconds, the terminal goes to
> "idle", meaning it has no network resources at all. Next time it
> wants to send something (or the network wants to deliver something
> to it), network resources need to be negotiated again. This can take
> 1-2 seconds and uses battery power of course. It also consumes
> resources in the operator network (because mobility control units
> need to talk to base stations, tunnels need to be re-negotiated
> etc).
> 
> Anyhow, my point is that not only is there a benefit in having
> multiple applications wake up at the same time for power reasons
> within the device, there is also a point in having coordination of
> their network access. If a device is running 3 IM programs at the
> same time, it'd be beneficial if they were coordinated in their
> communication with their Internet servers. Same goes for the "check
> for new email" application. If they all were optimized to only wake
> up the network connectivity once every 180 seconds instead of doing
> it when the individual application felt like it, power and other
> resources would be saved by all involved parties.

This is a good point.  Within some limits, the timer-aggregation
changes that have gone into Linux can handle this, but I am not sure
whether or not 180 seconds is within the reasonable boundaries for
timer jitter.

Of course, the timers might be synchronized upon wakeup after a
sufficiently long suspension, but they would not necessarily stay
synchronized without the help of some other mechanism, such as the
afore-mentioned timer-aggregation changes.

						Thanx, Paul
--
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/