Skip site navigation (1) Skip section navigation (2)

Re: Wierd context-switching issue on Xeon

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Tuckfield <paul(at)tuckfield(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Wierd context-switching issue on Xeon
Date: 2004-04-22 03:10:43
Message-ID: 18620.1082603443@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Paul Tuckfield <paul(at)tuckfield(dot)com> writes:
>> I used the taskset command:
>> taskset 01 -p <pid for backend of test_run.sql 1>
>> taskset 01 -p <pid for backend of test_run.sql 1>
>> 
>> I guess that 0 and 1 are the two cores (pipelines? hyper-threads?) on 
>> the first Xeon processor in the box.

AFAICT, what you've actually done here is to bind both backends to the
first logical processor of the first Xeon.  If you'd used 01 and 02
as the affinity masks then you'd have bound them to the two cores of
that Xeon, but what you actually did simply reduces the system to a
uniprocessor.  In that situation the context swap rate will be normally
one swap per scheduler timeslice, and at worst two swaps per timeslice
(if a process is swapped away from while it holds a lock the other one
wants).  It doesn't prove a lot about our SMP problem though.

I don't have access to a Xeon with both taskset and hyperthreading
enabled, so I can't check what happens when you do the taskset correctly
... could you retry?

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Dave CramerDate: 2004-04-22 03:18:47
Subject: Re: Wierd context-switching issue on Xeon patch for 7.4.1
Previous:From: Dave CramerDate: 2004-04-22 03:06:41
Subject: Re: Wierd context-switching issue on Xeon patch for 7.4.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group