Messages in this thread | | | Date | Thu, 27 Sep 2012 09:55:30 -0700 (PDT) | From | david@lang ... | Subject | Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected |
| |
On Thu, 27 Sep 2012, Borislav Petkov wrote:
> On Thu, Sep 27, 2012 at 12:17:22AM -0700, david@lang.hm wrote: >> It seems to me that trying to figure out if you are going to >> overload the L2 is an impossible task, so just assume that it will >> all fit, and the worst case is you have one balancing cycle where >> you can't do as much work and then the normal balancing will kick in >> and move something anyway. > > Right, and this implies that when the load balancer runs, it will > definitely move the task away from the L2. But what do I do in the cases > where the two tasks don't overload the L2 and it is actually beneficial > to keep them there? How does the load balancer know that?
no, I'm saying that you should assume that the two tasks won't overload the L2, try it, and if they do overload the L2, move one of the tasks again the next balancing cycle.
there is a lot of possible sharing going on between 'cores'
shared everything (a single core) different registers, shared everything else (HT core) shared floating point, shared cache, different everything else shared L2/L3/Memory, different everything else shared L3/Memory, different everything else shared Memory, different everything else different everything
and just wait a couple of years and someone will add a new entry to this list (if I haven't already missed a few :-)
the more that is shared, the cheaper it is to move the process (the less cached state you throw away), so ideally you want to move the process as little as possible, just enough to eliminate whatever the contended resource it. But since you really don't know the footprint of each process in each of these layers, all you can measure is what percentage of the total core time the process used, just move it a little and see if that was enough.
David Lang
| |