Thread (10 messages) 10 messages, 4 authors, 2012-06-22

Re: [PATCH] hugeltb: Mark hugelb_max_hstate __read_mostly

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2012-06-22 22:06:33

On Fri, 15 Jun 2012 09:50:00 -0500 (CDT)
Christoph Lameter [off-list ref] wrote:
On Fri, 15 Jun 2012, Michal Hocko wrote:
quoted
quoted
Thats all? There is no performance gain from this change?
Is that required in order to put data in the read mostly section?
I thought so. The read_mostly section is specially designed for data that
causes excessive cacheline bounces and has to be grouped with rarely
accessed other data. That was at least the intend when we created it.
The __read_mostly thing really is a bit of a crapshoot.  The runtime
effects are extremely dependent upon Kconfig settings and toolchain
behaviour.  I do recall one or two cases where people did fix
real-world observed performance issues by adding __read_mostly.

Literally "one or two".  We have more than one or two __read_mostly
annotations in there!

As that hugelb_max_hstate is write-once, it's a good candidate.  I'll
apply the patch and hope that it improves someone's kernel somewhere
someday.  Shrug.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help