On Mon, 2 Jul 2012 23:54:09 +0530 Chinmay V S <cvs268@xxxxxxxxx> wrote: > Hi Vlad, > > I suppose we both are looking at opposite sides of the same coin. > While i am wary of the potential pitfalls, > you have focused on the benefits of using __read_mostly. > > At this point i would like to send out a shout to everyone concerned to please > clarify the status of __read_mostly: > > 1. Is it being actively pursued? (systems that *will* clearly benefit from it) > 2. Any actual results on real world use-cases? (w/ & w/o __read_mostly) > 3. Is __read_mostly being accepted in non-architecture specific kernel code? > 4. Is anyone working on a potential replacement for it? I don't recall ever having seen any serious work justifying or condemning __read_mostly. It's one of those things which seemed a good idea at the time, got added and nobody did anything further with it, as far as I know. I've always been rather wobbly about it, for reasons discussed up-thread. As for this particular patch: I've not seen any reason to do anything with it, because the changelog doesn't describe why the patch is needed. If some performance problem has been encountered then that should have been fully described in the patch changelog. If some problem has indeed been observed then an alternative to __read_mostly is to pad bh_cachep to a cacheline boundary with ____cacheline_aligned_in_smp or similar. Or, perhaps better, identify the variable which bh_cachep is sharing with, and pad *that* variable to a cacheline so it can't cause cache thrashing with something else in the future. And once this mystery variable is identified, we can perhaps beneficially group it into the same cacheline with some other variables which are related to it. But I'm madly guessing and can't say aything dispositive or even useful, because we haven't been told what the problem was. Still. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
