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
Hi,
we have a complex modperl database application using postgresql 7.4.1 on
a new Dual Xeon MP Machine with SLES8 which seems to generate too much
context switches (way more than 100.000) on higher load (meaning system
load 2). System response times significantly slow down then. We have
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
