On Tue, Oct 29, 2013 at 5:56 PM, Jesse Gross <[email protected]> wrote: > On Tue, Oct 29, 2013 at 3:57 PM, Alexei Starovoitov > <[email protected]> wrote: >> On Tue, Oct 29, 2013 at 3:00 PM, Jesse Gross <[email protected]> wrote: >>> On Tue, Oct 29, 2013 at 11:19 AM, Alexei Starovoitov >>> <[email protected]> wrote: >>>> On Tue, Oct 29, 2013 at 11:15 AM, Pravin Shelar <[email protected]> wrote: >>>>> On Tue, Oct 29, 2013 at 10:24 AM, Andy Zhou <[email protected]> wrote: >>>>>> This is not a review, but it would be nice to add some code comments in >>>>>> proper data structure layout, so that the same logic can be followed in >>>>>> the >>>>>> future. >>>>>> >>>>> ok, I will add general guideline in datapath.h as follows: >>>>> >>>>> /* >>>>> * data structure members should be arranged according to frequency of >>>>> access >>>>> * in ovs fast-path. So that most frequently accessed members are in >>>>> first cache-line >>>>> * for a datapath object. >>>>> */ >>>> >>>> that may be fine as general rule, but I don't see how it helps to >>>> avoid cache misses. >>> >>> It reduces cache pressure by not polluting cache lines with data that >>> won't be commonly accessed. >> >> exactly. "commonly accessed" is not the same as "sorted by frequency". >> if field b accessed right after a, you want them to be in the same >> cache line and ordered as a,b >> If struct has a lot of fields, sorting them by number of accesses may >> actually degrade performance. >> Some compilers actually able to do field reordering with profile >> feedback and they don't sort fields by frequency. >> As a general rule, if 'b' accessed usually after 'a', you want them to >> be in the order: a,b >> Even if overall 'b' accessed more frequently than 'a', since fill of >> the cache line is not instant and comes in chunks, for ordered stores >> cpu can do store coalescing. > > That's generally true but it's not clear to me what specifically you > are proposing to be done.
was questioning whether commit message of 'frequency of access' should apply as general rule or not. Nothing against the actual change if performance numbers are backing it up. Are they? _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
