Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to3.6-rc5 on AMD chipsets - bisected
From: david
Date: Thu Sep 27 2012 - 12:56:27 EST
On Thu, 27 Sep 2012, Borislav Petkov wrote:
On Thu, Sep 27, 2012 at 12:17:22AM -0700, david@xxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/