On Fri, 15 Jun 2012 09:50:00 -0500 (CDT) Christoph Lameter <cl@xxxxxxxxx> wrote: > On Fri, 15 Jun 2012, Michal Hocko wrote: > > > > 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>