> On 29 Oct 2014, at 2:44 am, Mike Belopuhov <m...@belopuhov.com> wrote: > > On 28 October 2014 17:02, Ted Unangst <t...@tedunangst.com> wrote: >> On Tue, Oct 28, 2014 at 16:49, David Gwynne wrote: >>> when i shuffled the locking in pools around, page colouring was >>> left behind. >>> >>> page colouring is where you offset items within a page if you have >>> enough slack space. the previous implementation simply incremented >>> the colour so each new page got the next offset. i didnt do this >>> because the page and its items are now initted outside the lock, >>> so maintaining that curcolour iterator wasnt as easy. >>> >>> this sidesteps the curcolor maintenance by just having each page >>> randomly pick a colour when it's set up. >> >> Would it make more sense to use the page address to pick the color?
yeah. or we could derive it from a counter in the pool like the item or page get counters > Does it actually still make sense to keep page coloring? Is there still > benefit on modern hardware? if you want it to go fast, it would make more sense to set the item alignment in pool_init to the size of the cacheline. colouring would then become irrelevant from a speed perspective. however, if colouring is more about perturbing item addresses then it may still be worth it. eg, if you only fit one item on a page, without colouring your item addresses will always be on a page boundary. moving it around might flush out assumptions about low bits in addresses. i dunno. im fine with either removing colouring altogether or setting it from something else completely. i just want a decision to be made cos right now ph_color isnt set, which is a bug.
