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, 14 Jun 2010 00:46:48 -0700
From:	Suresh Rajashekara <suresh.raj+linuxomap@...il.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-omap@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	linux-pm@...ts.linux-foundation.org
Subject: Re: Timekeeping issue on aggressive suspend/resume

On Thu, Jun 10, 2010 at 12:52 PM, john stultz <johnstul@...ibm.com> wrote:
> I think Thomas was suggesting that you consider creating a option for
> where CLOCK_MONOTONIC included total_sleep_time.
>
> In that case the *hack* (and this is a hack, we'll need some more
> thoughtful discussion before anything like it could make it upstream)
> would be in timekeeping_resume() to comment out the lines that update
> wall_to_monotonic and total_sleep_time.
>
> It would be interesting to hear if that hack works for you, and we can
> try to come up with a better way to think about how to accommodate both
> views of how to account time over suspend.

Thanks.

I tried this fix. It seemed to help, however the accuracy of sleep
time for the process was not quite right. A process thread which was
supposed to wake up every (X) seconds, seemed to wake up every (X -
delta X) seconds.

Also another side effect of this change was that the system time was
no longer in sync with the wall time.

These problems were more pronounced when the suspend/wakeup cycle time
was brought down to 0.5 seconds from 4 seconds. The periodicity of
most of the process threads were disturbed.

I decided to NOT suspend/resume the timekeeping subsystem in the
kernel and try. It seemed to work. Every application seems to work
fine.

Now my question is; Is it safe to disable suspend/resume of the
timekeeping subsystem? Will it have an effect (on
functionality/performance) which may not surface in my short
experiments?

Thanks in advance,

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ