Could this be related to the O(1) scheduler backpatches from 2.6 to 2.4
kernel on newer 2.4er distros (RedHat, SuSE)?
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Improve spinlock code for recent x86 processors: insert a PAUSE
instruction in the s_lock() wait loop, and use test
Don't think so, mine is a vanilla kernel from kernel.org
Dave
On Thu, 2004-04-15 at 16:03, Dirk Lutzebaeck wrote:
Could this be related to the O(1) scheduler backpatches from 2.6 to 2.4
kernel on newer 2.4er distros (RedHat, SuSE)?
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Isn't this a linux kernel issue ?
My understanding is that the scheduler doesn't know that 2 of the CPU's
are actually the same underlying hardware and sometimes two contexts end
up fighting for the same underlying chip?
--dc--
On Thu, 2004-04-15 at 16:37, Josh Berkus wrote:
Folks,
I am
Joe, do you know where I should look in the 7.4.2 code to find this out?
Dirk
Joe Conway wrote:
Dirk Lutzebäck wrote:
postgresql 7.4.1
a new Dual Xeon MP
too much context switches (way more than 100.000) on higher load
(meaning system load 2).
I believe this was fixed in 7.4.2, although
Dirk Lutzebäck wrote:
Joe, do you know where I should look in the 7.4.2 code to find this out?
I think I was wrong. I just looked in CVS and found the commit I was
thinking about:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/storage/lmgr/s_lock.c.diff?r1=1.22r2=1.23
Joe Conway [EMAIL PROTECTED] writes:
Improve spinlock code for recent x86 processors: insert a PAUSE
instruction in the s_lock() wait loop, and use test before test-and-set
in TAS() macro to avoid unnecessary bus traffic. Patch from Manfred
Spraul, reworked a bit by Tom.
I thought this had
Folks,
I am currently chasing what seems to be the same issue: massive context
swapping on a dual Xeon system. I tried back-patching the above-mentioned
patch ... it helps a little but by no means solves the problem ...
BTW, I'm currently pursuing the possibility that this has something to
