Re: Wierd context-switching issue on Xeon patch for 7.4.1 - Mailing list pgsql-performance

From Tom Lane
Subject Re: Wierd context-switching issue on Xeon patch for 7.4.1
Date
Msg-id 20171.1082610827@sss.pgh.pa.us
Whole thread Raw
In response to Re: Wierd context-switching issue on Xeon patch for 7.4.1  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Wierd context-switching issue on Xeon patch for 7.4.1
List pgsql-performance
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> For BSDOS it has:

>     #if (CLIENT_OS == OS_FREEBSD) || (CLIENT_OS == OS_BSDOS) || \
>         (CLIENT_OS == OS_OPENBSD) || (CLIENT_OS == OS_NETBSD)
>     { /* comment out if inappropriate for your *bsd - cyp (25/may/1999) */
>       int ncpus; size_t len = sizeof(ncpus);
>       int mib[2]; mib[0] = CTL_HW; mib[1] = HW_NCPU;
>       if (sysctl( &mib[0], 2, &ncpus, &len, NULL, 0 ) == 0)
>       //if (sysctlbyname("hw.ncpu", &ncpus, &len, NULL, 0 ) == 0)
>         cpucount = ncpus;
>     }

Multiplied by how many platforms?  Ewww...

I was wondering about some sort of dynamic adaptation, roughly along the
lines of "whenever a spin loop successfully gets the lock after
spinning, decrease the allowed loop count by one; whenever we fail to
get the lock after spinning, increase by 100; if the loop count reaches,
say, 10000, decide we are on a uniprocessor and irreversibly set it to
1."  As written this would tend to incur a select() delay once per
hundred spinlock acquisitions, which is way too much, but I think we
could make it work with a sufficiently slow adaptation rate.  The tricky
part is that a slow adaptation rate means we can't have every backend
figuring this out for itself --- the right value would have to be
maintained globally, and I'm not sure how to do that without adding a
lot of overhead.

            regards, tom lane

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Wierd context-switching issue on Xeon patch for 7.4.1
Next
From: Tom Lane
Date:
Subject: Re: 225 times slower