linux-kernel - Re: Memory management timer optimizations for power saving

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]

Message-ID: <20090518195010.0d0ba10b@lxorguk.ukuu.org.uk>
Date:	Mon, 18 May 2009 19:50:10 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	<Tero.Kristo@...ia.com>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: Memory management timer optimizations for power saving

On Mon, 18 May 2009 14:40:59 +0200
<Tero.Kristo@...ia.com> wrote:

> Hi,
> 
> I've been looking at some timer optimizations for the kernel to get it to sleep as long as possible, and to allow maximum power saving in embedded ARM environment. One of the most severe timer users appears to be memory management, with reap_work and wb_timer expiring rather often (I am seeing something like one timer expiring every two seconds or so.) In the attached patch I have changed the timers to deferred type, i.e. they can be delayed until next wakeup occurs from some other source, like another timer or some peripheral I/O. Can you see any problems doing something like this? A potential issue could be that some data writeback to permanent storage gets delayed, and in case of a sudden power loss it might be lost completely.

There was an old thread where there were discussions about adding an
accuracy to timers was discussed (its relevant for virtual machines as
well where you want the timers to be handled by the hypervisor and
clustered). It certainly makes sense to add the ability to mark some
timers as ranges. Linus argued that for almost all timers you could set
an accuracy range as a fraction of the timeout value without fixing them
all up.

Another question would be whether reap_work and wb_timer could in fact be
smarter so they don't run so much but get started when really needed.

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