Date: Mon, 28 Nov 2016 08:27:10 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Anton Yuzhaninov <citrin+bsd@citrin.ru> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: __read_only in the kernel Message-ID: <CAJ-Vmom49fcKn-oqhG_aF017wjUiJNZtg9rmuacRRRyG6tuXpQ@mail.gmail.com> In-Reply-To: <f7e149c1-5ec4-60e5-2c5c-d9062091fc63@citrin.ru> References: <20161127212503.GA23218@dft-labs.eu> <CABh_MKnPwmALT6Bj_y5xUikYbrKsFykvFQ3Fk-921eSAgi_yVw@mail.gmail.com> <f7e149c1-5ec4-60e5-2c5c-d9062091fc63@citrin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
.. and it makes it easy to see (a) whether a variable has it, and (b) whether a variable doesn't - just use grep. -a On 28 November 2016 at 07:16, Anton Yuzhaninov <citrin+bsd@citrin.ru> wrote: > On 11/28/16 03:30, Ed Schouten wrote: >> >> 2016-11-27 22:25 GMT+01:00 Mateusz Guzik <mjguzik@gmail.com>: >>> >>> The somewhat standard way of combating parts of it for frequently read >>> and rarely (if ever) modified variables is an annotation which puts >>> them in a dedicated part of the binary and the somewhat standard name >>> for a macro doing the work is __read_mostly. >> >> >> Out of curiosity, what is the advantage of doing this? > > > If a variable which read often shares CPU cache line with a variable updated > often we have performance degradation. Each time second variable is updated > first (read mostly) unnecessary flushed from CPU cache. > > Some data structures already aligned by cache line size to avoid false > sharing, but moving read only / read mostly variables to separate section > allows to avoid false sharing without spending memory on alignment (and > alignment not always helps to avoid false sharing AFAIK). > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom49fcKn-oqhG_aF017wjUiJNZtg9rmuacRRRyG6tuXpQ>