Re: Wierd context-switching issue on Xeon

Ooops, what I meant to say was that 2 threads bound to one
(hyperthreaded) cpu does *NOT* cause the storm, even on an smp xeon.

Therefore, the context switches may be a result of cache coherency
related delays.  (2 threads on one hyperthreaded cpu presumably have
tightly coupled 1,l2 cache.)

On Apr 20, 2004, at 1:02 PM, Paul Tuckfield wrote:

> I tried to test how this is related to cache coherency, by forcing
> affinity of the two test_run.sql processes to the two cores
> (pipelines? threads) of a single hyperthreaded xeon processor in an
> smp xeon box.
>
> When the processes are allowed to run on distinct chips in the smp
> box, the CS storm happens.  When they are "bound" to the two cores of
> a single hyperthreaded Xeon in the smp box, the CS storm *does*
> happen.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ er, meant *NOT HAPPEN*
>
>
>
> 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.
>
> I did this on RedHat Fedora core1 on an intel motherboard (I'll get
> the part no if it matters)
>
> during storms :  300k CS/sec, 75% idle (on a dual xeon (four core))
> machine (suggesting serializing/sleeping processes)
> no storm:   50k CS/sec,  50% idle (suggesting 2 cpu bound processes)
>
>
> Maybe there's a "hot block" that is bouncing back and forth between
> caches? or maybe the page holding semaphores?
>
> On Apr 19, 2004, at 5:53 PM, Tom Lane wrote:
>
>> I wrote:
>>> Here is a test case.
>>
>> Hmmm ... I've been able to reproduce the CS storm on a dual Athlon,
>> which seems to pretty much let the Xeon per se off the hook.  Anybody
>> got a multiple Opteron to try?  Totally non-Intel CPUs?
>>
>> It would be interesting to see results with non-Linux kernels, too.
>>
>>             regards, tom lane
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faqs/FAQ.html
>