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: <20090507205101.0091eb2a@lxorguk.ukuu.org.uk>
Date:	Thu, 7 May 2009 20:51:01 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Christoph Lameter <cl@...ux.com>,
	Alok Kataria <akataria@...are.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: Reduce the default HZ value

O> We care only about a decreasing time interval.  This interval is passed 
> to register polling functions (bitbang no longer than <this> amount of 
> time), as well as _cumulatively_ affecting the entire EH [sub-]process.

Yes so its a simple timer.

> A timer-based solution, in addition to being an ugly hack, would imply 
> replacing a simple variable with _at least_ two spinlocks, plus a timer 
> callback function that simply says "I expired".  With loops such as

That simple variable is incredibly incredibly expensive in power, in CPU
use, in cache poisoning and more - its very misleading to think of it as
"free".

> The current code is a -lot- more simple than checking "is timer 
> expired?" all over the code, given that any sort of timer-based function 
> implies dealing with additional concurrency issues -- a complication the 
> libata EH does not need.

I disagree - your implementation seems very very ugly. But even then its
a case of swapping jiffies for jiffies() for unconverted code and using
that function read the timer value from somewhere. The important thing is
that asking the time is active and we don't burn processor time and
wakeups and power going "lets wake up, lets turn the cache on, lets load
some cache lines, lets increment a variable, and poke some lines on the
bus waking up bits of other logic, now lets write the cache back out, and
go back to sleep for a tiny amount of time"

jiffies is *really* expensive...

Even a 

	jiffies = time_count_begin();

	blah blah with jiffies;

	time_count_end();

would help. But that seems a good way to add bugs.

However you don't need HZ - you are using it to implement state changes
and you can do that really easily by making your timer switch a single
value to the correct state for the time and in your loops just checking

	while ( ap->reset_state == WIBBLING_RANDOMLY) {
		wobble = readl(ap->ioaddr.wibble);
		mdelay(1);
		if (wobble & WIBBLED) {
			...
		}
	}




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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ