Re: futex results with dbt-3
От | Dave Cramer |
---|---|
Тема | Re: futex results with dbt-3 |
Дата | |
Msg-id | 41770285.5090604@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: futex results with dbt-3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Forgive my naivete, but do futex's implement some priority algorithm for which process gets control. One of the problems as I understand it is that linux does (did ) not implement a priority algorithm, so it is possible for the context which just gave up control to be the next context woken up, which of course is a complete waste of time. --dc-- Tom Lane wrote: >Manfred Spraul <manfred@colorfullife.com> writes: > > >>Tom Lane wrote: >> >> >>>The bigger problem here is that the SMP locking bottlenecks we are >>>currently seeing are *hardware* issues (AFAICT anyway). The only way >>>that futexes can offer a performance win is if they have a smarter way >>>of executing the basic atomic-test-and-set sequence than we do; >>> >>> >>> >>lwlocks operations are not a basic atomic-test-and-set sequence. They >>are spinlock, several nonatomic operations, spin_unlock. >> >> > >Right, and it is the spinlock that is the problem. See discussions a >few months back: at least on Intel SMP machines, most of the problem >seems to have to do with trading the spinlock's cache line back and >forth between CPUs. It's difficult to see how a futex is going to avoid >that. > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > > > -- Dave Cramer www.postgresintl.com 519 939 0336 ICQ#14675561
В списке pgsql-performance по дате отправления: