Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance

On Tue, Jan 14, 2014 at 11:39 AM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> On 01/14/2014 09:39 AM, Claudio Freire wrote:
>> On Tue, Jan 14, 2014 at 5:08 AM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
>>> Again, as said above the linux file system is doing fine. What we
>>> want is a few ways to interact with it to let it do even better when
>>> working with postgresql by telling it some stuff it otherwise would
>>> have to second guess and by sometimes giving it back some cache
>>> pages which were copied away for potential modifying but ended
>>> up clean in the end.
>> You don't need new interfaces. Only a slight modification of what
>> fadvise DONTNEED does.
>>
>> This insistence in injecting pages from postgres to kernel is just a
>> bad idea.
> Do you think it would be possible to map copy-on-write pages
> from linux cache to postgresql cache ?
>
> this would be a step in direction of solving the double-ram-usage
> of pages which have not been read from syscache to postgresql
> cache without sacrificing linux read-ahead (which I assume does
> not happen when reads bypass system cache).
>
> and we can write back the copy at the point when it is safe (from
> postgresql perspective) to let the system write them back ?
>
> Do you think it is possible to make it work with good performance
> for a few million 8kb pages ?

I don't think so. The kernel would need to walk the page mapping on
each page fault, which would incurr the cost of a read cache hit on
each page fault.

A cache hit is still orders of magnitude slower than a regular page
fault, because the process page map is compact and efficient. But if
you bloat it, or if you make the kernel go read the buffer cache, it
would mean bad performance for RAM access, which I'd venture isn't
really a net gain.

That's probably the reason there is no zero-copy read mechanism.
Because you always have to copy from/to the buffer cache anyway.

Of course, this is just OTOMH. Without actually benchmarking, this is
all blabber.

>> At the very worst, it may
>> introduce serious security and reliability implications, when
>> applications can destroy the consistency of the page cache (even if
>> full access rights are checked, there's still the possibility this
>> inconsistency might be exploitable).
> If you allow write() which just writes clean pages, I can not see
> where the extra security concerns are beyond what normal
> write can do.

I've been working on security enough to never dismiss any kind of
system-level inconsistency.

The fact that you can make user-land applications see different data
than kernel-land code has over-reaching consequences that are hard to
ponder.