Re: slow dropping of tables, DropRelFileNodeBuffers, tas

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: slow dropping of tables, DropRelFileNodeBuffers, tas
Дата
Msg-id CA+CSw_tL8U3W41cAhSi2Bjt=3+hRAxpG-HZqF9KHHB6XmYtwCw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Wed, May 30, 2012 at 2:10 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Also, I wonder if DropRelFileNodeBuffers() could scan the pool without
> grabbing the spinlocks on every buffer? It could do an unlocked test first,
> and only grab the spinlock on buffers that need to be dropped.

The scanning of buffers seemed awfully slow to me. Doing the math it
ends up being somewhere around 120ns per buffer, about consistent with
a full cache miss. It looks like the spinlock tas implementation (lock
xchgb) is preventing prefetching. This suspicion is corroborated by
the following comment in Linux kernels per_cpu.h:

/** xchg is implemented using cmpxchg without a lock prefix. xchg is* expensive due to the implied lock prefix.  The
processorcannot prefetch* cachelines if xchg is used.*/ 

I'm not sure, but doing an unlocked test first might also be useful in
triggering the prefetchers. The CPU should be doing a lot better than
the current ~4.3GB/s when scanning buffer descriptors.

Of course not scanning at all or doing less scans at the expense of
more work in the inner loop would be even better.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: too low NAPTIME_PER_CYCLE /too many wakeups in walreceiver.c
Следующее
От: Bruce Momjian
Дата:
Сообщение: Figuring out shared buffer pressure