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]>
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 befo
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
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
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
Joe,
> I believe this was fixed in 7.4.2, although I can't seem to find it in
> the release notes.
Depends on the cause of the issue. If it's the same issue that I'm currently
struggling with, it's not fixed.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
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.22&r2=1.23
http:/
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:
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 I can't seem to find it in
the release notes.
Joe
---(end of broadcast)
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
tun
10 matches
Mail list logo