On Wed, Apr 13, 2016 at 10:59 AM, Andres Freund <and...@anarazel.de> wrote:
>> but as an example, if I only see such regression on a Linux kernel >> with version a version < 3.8 I am going to be less concerned about >> getting something into 9.6, since IMO it is completely irresponsible >> to run a NUMA machine with 4 or more nodes on an OS with a substandard >> NUMA scheduler. I'm not sure when 3.8 became available, but according >> to Wikipedia Version 3.10 of the Linux kernel was released in June >> 2013, so it's not like you need to be on the bleeding edge to have a >> decent scheduler. > > I don't think effect of adding a single spinlock (an exclusive lock!) in > a hot path is likely to be hugely dependant on the kernel version. My experience is that is easily can be. We had a customer who could not scale beyond a certain point due to spinlock contention on a single spinlock already present in stock pg. We tried lots of config tweaks and a some custom patches to no avail. Then we had them upgrade from RHEL 6.latest to RHEL 7.latest, and they could scale much, much farther. No OS or pg config changes were made at the same time. The difference is that they went from kernel version kernel 2.6.32 to kernel version 3.10.0. The early version 3 kernels had a NUMA scheduler rewrite that was a disaster compared to 2.6.32. They rewrote it again in 3.8, with dramatic effect. > We've had such cases before, and felt the pain. E.g. the spinlock in the > ProcArrayLock used to be a *HUGE* contention point, and it has pretty > much the same acquisition pattern as this spinlock now. It would be great to have improvements in such access patterns, no doubt. I'll be happy if we get there. I don't have a problem trying to contribute to the effort, either, if people think that might actually be a net gain. But if we have a point where those not using the new feature are unaffected, and the question is about the range of workloads where the new feature will be helpful in 9.6, it doesn't seem to me to rise to the level of a bug or a release blocker. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers