futex
Hi all,
I knew there was an evaluation on the futex vs spinlock,
and Josh Berkus on IRC told me that there was only a 20%
performance increase, is this increase to throw away ?
Regards
Gaetano Mendola
Gaetano,
I knew there was an evaluation on the futex vs spinlock,
and Josh Berkus on IRC told me that there was only a 20%
performance increase, is this increase to throw away ?
Before we get totally off track here ....
I evaluated futexes strictly as an attempt to solve the context switch storm
bug. I did NOT test whether they improved performance overall.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Import Notes
Reply to msg id not found: 20040825010318.45CF05E46C4@svr1.postgresql.orgReference msg id not found: 20040825010318.45CF05E46C4@svr1.postgresql.org | Resolved by subject fallback
Josh Berkus wrote:
Gaetano,
I knew there was an evaluation on the futex vs spinlock,
and Josh Berkus on IRC told me that there was only a 20%
performance increase, is this increase to throw away ?Before we get totally off track here ....
I evaluated futexes strictly as an attempt to solve the context switch storm
bug. I did NOT test whether they improved performance overall.
What did you test exactly and could you explain a bit about the context
switch storm?
Did you use the futex interface directly or pthread_rwlock_rdlock?
--
Manfred
Manfred,
What did you test exactly and could you explain a bit about the context
switch storm?
PostgreSQL currently causes a CS storm (context switches > 100,000) on
multi-processor machines where you have a number of concurrent processes ( >
than the number of processors) accessing the same small quantity of data
repeatedly, particularly if doing seq scans and/or bad queries. This issue
causes a significant drop in server performance, as much as 60%.
Did you use the futex interface directly or pthread_rwlock_rdlock?
I'll have to admit to having only a beginner's grasp of this stuff, but I do
believe that that was what the OSDL patch did. Jan also tried a simpler
patch, which didn't work either. Both Jan and Tom have expressed the
opinion that the only solution is to make the BufrMgrLock more granular (as
in, not monolithic) but this is a huge task.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Josh Berkus wrote:
I'll have to admit to having only a beginner's grasp of this stuff, but I do
believe that that was what the OSDL patch did. Jan also tried a simpler
patch, which didn't work either. Both Jan and Tom have expressed the
opinion that the only solution is to make the BufrMgrLock more granular (as
in, not monolithic) but this is a huge task.
It's worth noting that I did a lot of work toward that goal (making the
BufMgrLock more granular) earlier in 2004, but unfortunately wasn't able
to get it finished before leaving for the summer. I can't guarantee that
the approach I took was the right one, but if anyone's interested in
working on this area then it might save some time to start with previous
work. I want to take another shot at doing this for 8.1, although I
don't know right now if I'll be able to.
-Neil
Neil,
It's worth noting that I did a lot of work toward that goal (making the
BufMgrLock more granular) earlier in 2004, but unfortunately wasn't able
to get it finished before leaving for the summer. I can't guarantee that
the approach I took was the right one, but if anyone's interested in
working on this area then it might save some time to start with previous
work. I want to take another shot at doing this for 8.1, although I
don't know right now if I'll be able to.
Jan was interested in working on this as well; we hashed it out this summer.
--
Josh Berkus
Aglio Database Solutions
San Francisco