linux-kernel - Re: PATCH] cpuidle: A new variant of the menu governor to boost IO performance

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: <4AAE0841.6000305@kernel.org>
Date:	Mon, 14 Sep 2009 18:09:21 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, lenb@...nel.org, mingo@...e.hu,
	yanmin_zhang@...ux.intel.com, torvalds@...ux-foundation.org,
	jens.axboe@...cle.com, David Howells <dhowells@...hat.com>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Subject: Re: PATCH] cpuidle: A new variant of the menu governor to boost IO
 performance

Hello,

Peter Zijlstra wrote:
>> If someone has any better ideas, I would happy to remove the annoying
>> restriction.
> 
> That sounds like a variable __attribute__((no-explicit-relocs)) should
> be proposed to the GCC folks or something. Then we can at least have a
> hope of lifting this restriction some time in the future.
> 
> (Alternatively we build the full alpha kernel with
> --mno-explicit-relocs, but that would be sub-optimal as well)
> 
> Not sure if s390 has anything similar..

If possible, something like __attribute__((dont-expect-it-to-be-near))
would be very nice in this case.

> Alternatively we could file it as a bug, since the symbols are in a
> custom .section, which is a strong indication we're going to play funny
> games anyway.

This sounds quite appealing but I think it has certain possibility of
coming back and bite us in the rear.

Hmmm... Offsets for symbols which fit in the first chunk are
guaranteed to be addressable with the reduced range and thus the weak
trick is only necessary for modules, so a solution we can implement in
kernel proper is to reserve address range for module text and data to
be loaded near the builtin text and data.  Percpu already supports
reservation in the first chunk (for x86-64 for example) so that part
is already there.  Ah... only if s390 and alpha are a little easier to
come by.  :-(

Thanks.

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