Re: Bug: Buffer cache is not scan resistant - Mailing list pgsql-hackers

From Luke Lonergan
Subject Re: Bug: Buffer cache is not scan resistant
Date
Msg-id C3E62232E3BCF24CBA20D72BFDCB6BF802CFC0C0@MI8NYCMAIL08.Mi8.com
Whole thread Raw
In response to Re: Bug: Buffer cache is not scan resistant  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug: Buffer cache is not scan resistant  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> So either way, it isn't in processor cache after the read.
> So how can there be any performance benefit?

It's the copy from kernel IO cache to the buffer cache that is L2
sensitive.  When the shared buffer cache is polluted, it thrashes the L2
cache.  When the number of pages being written to in the kernel->user
space writes fits in L2, then the L2 lines are "written through" (see
the link below on page 264 for the write combining features of the
opteron for example) and the writes to main memory are deferred.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
25112.PDF

- Luke



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug: Buffer cache is not scan resistant
Next
From: "Luke Lonergan"
Date:
Subject: Re: Bug: Buffer cache is not scan resistant