This week at LWN: How 3.6 nearly broke PostgreSQL

Posted by Scott_Ruecker on Oct 13, 2012 1:32 PM EDT
LWN.net; By Jonathan Corbet
Mail this story
Print this story

In mid-September, the 3.6 kernel appeared to be stabilizing nicely. Most of the known regressions had been fixed, the patch volume was dropping, and Linus was relatively happy. Then Nikolay Ulyanitsky showed up with a problem: the pgbench PostgreSQL benchmark ran 20% slower than under 3.5. The resulting discussion shows just how hard scalability can be on contemporary hardware and how hard scheduling can be in general. Borislav Petkov was able to reproduce the problem; a dozen or so bisection iterations later he narrowed down the problem to this patch, which was duly reverted. There is just one little problem left: the offending patch was, itself, meant to improve scheduler performance. Reverting it fixed the PostgreSQL regression, but at the cost of losing an optimization that improves things for many (arguably most) other workloads. Naturally, that led to a search to figure out what the real problem was so that the optimization could be restored without harmful effects on PostgreSQL.

Full Story

  Nav
» Read more about: Story Type: News Story; Groups: Kernel

« Return to the newswire homepage

This topic does not have any threads posted yet!

You cannot post until you login.