Messages in this thread | | | From | Anton Blanchard <> | Date | Sun, 11 Mar 2001 17:26:29 +1100 | Subject | Re: kernel lock contention and scalability |
| |
Hi,
> Thanks for looking into postgresql/pgbench related locking. Yes, > apparently postgresql uses a synchronization scheme that uses select() > to effect delays for backing off while attempting to acquire a lock. > However, it seems to me that runqueue lock contention was not entirely due > to postgresql code, since it was largely alleviated by the multiqueue > scheduler patch.
Im not saying that the multiqueue scheduler patch isn't needed, just that this test case is caused by a bug in postgres. We shouldn't run around fixing symptoms - dropping the contention in the runqueue lock might not change the overall performance of the benchmark, on the other hand fixing the spinlocks in postgres probably will.
On the other hand, if postgres still pounds on the runqueue lock after the bug has been fixed then we need to look at the multiqueue patch.
Cheers, Anton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |