On Tue, 2003-07-22 at 11:50, Bruce Momjian wrote:
> Jord Tanner wrote:
> > On Tue, 2003-07-22 at 10:39, Bruce Momjian wrote:
> > > But CPU affinity isn't realated to hyperthreading, as far as I know.
> > > CPU affinity tries to keep processes on the same cpu in case there is
> > > still valuable info in the cpu cache.
> > >
> >
> > It is true that CPU affinity is designed to prevent the dump of valuable
> > CPU cache. My thought is that if you are trying to prevent CPU
> > contention, you could use CPU affinity to prevent 2 postmaster processes
> > from running simultaneously on the same die. Am I out to lunch here?
> > I've not worked with CPU affinity before, so I'm not familiar with the
> > intimate details.
>
> I guess you could but it is the backends that use the cpu. I don't
> think manually specifying affinity will work for most applications.
This is beating a dead horse, but I'll take one more kick at it.
CPU affinity is defined by a bit mask, so multiple processors can be
selected. It is also inherited by child processes, so assigning CPU 0
and CPU 2 (which I assume would be on different dies in a dual processor
hyper-threading system) to the parent postmaster should prevent CPU
contention with respect to the postgres backend.
I would be very interested to see if any advantage could be gained by a
combination of multiple HT processors and cpu affinity over multiple
non-HT processors. Yet Another Performance Testing To Do (YAPTTD)!
--
Jord Tanner <jord@indygecko.com>
