Mel, > I'm the chair for Linux Storage, Filesystem and Memory Management Summit 2014 > (LSF/MM). A CFP was sent out last month (https://lwn.net/Articles/575681/) > that you may have seen already. > > In recent years we have had at least one topic that was shared between > all three tracks that was lead by a person outside of the usual kernel > development community. I am checking if the PostgreSQL community > would be willing to volunteer someone to lead a topic discussing > PostgreSQL performance with recent kernels or to highlight regressions > or future developments you feel are potentially a problem. With luck > someone suitable is already travelling to the collaboration summit > (http://events.linuxfoundation.org/events/collaboration-summit) and it > would not be too inconvenient to drop in for LSF/MM as well.
We can definitely get someone there. I'll certainly be there; I'm hoping to get someone who has closer involvement with our kernel interaction as well. > There are two reasons why I'm suggesting this. First, PostgreSQL was the > basis of a test used to highlight a scheduler problem around kernel 3.6 > but otherwise in my experience it is rare that PostgreSQL is part of a > bug report. I am skeptical this particular bug report was a typical use > case for PostgreSQL (pgbench, read-only, many threads, very small in-memory > database). I wonder why reports related to PostgreSQL are not more common. > One assumption would be that PostgreSQL is perfectly happy with the current > kernel behaviour in which case our discussion here is done. To be frank, it's because most people are still running on 2.6.19, and as a result are completely unaware of recent developments. Second, because there's no obvious place to complain to ... lkml doesn't welcome bug reports, and where else do you go? > Does the PostgreSQL community have a problem with recent kernels, > particularly with respect to the storage, filesystem or memory management > layers? If yes, do you have some data that can highlight this and can you > volunteer someone to represent your interests to the kernel community? Yes, and yes. > Are > current developments in the IO layer counter to the PostgreSQL requirements? > If so, what developments, why are they a problem, do you have a suggested > alternative or some idea of what we should watch out for? Mostly the issue is changes to the IO scheduler which improve one use case at the expense of others, or set defaults which emphasize desktop hardware over server hardware. What also came up with the recent change to LRU is that the Postgres community apparently has more experience than the Linux community with buffer-clearing algorithms, and we ought to share that. > The track topic > would be up to you but just as a hint, we'd need something a lot more > concrete than "you should test more". How about "don't add major IO behavior changes with no backwards-compatibility switches"? ;-) Seriously, one thing I'd like to get out of Collab would be a reasonable regimen for testing database performance on Linux kernels. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
