Re: Bug: Buffer cache is not scan resistant

<p><font size="2">Incidentally, we tried triggering NTA (L2 cache bypass) unconditionally and in various patterns and
didnot see the substantial gain as with reducing the working set size.<br /><br /> My conclusion: Fixing the OS is not
sufficientto alleviate the issue.  We see a 2x penalty (1700MB/s versus 3500MB/s) at the higher data rates due to this
effect.<br/><br /> - Luke<br /><br /> Msg is shrt cuz m on ma treo<br /><br />  -----Original Message-----<br /> From:
 Sherry Moore [<a href="mailto:sherry.moore@sun.com">mailto:sherry.moore@sun.com</a>]<br /> Sent:   Tuesday, March 06,
200710:05 PM Eastern Standard Time<br /> To:     Simon Riggs<br /> Cc:     Sherry Moore; Tom Lane; Luke Lonergan; Mark
Kirkwood;Pavan Deolasee; Gavin Sherry; PGSQL Hackers; Doug Rady<br /> Subject:        Re: [HACKERS] Bug: Buffer cache
isnot scan resistant<br /><br /> Hi Simon,<br /><br /> > and what you haven't said<br /> ><br /> > - all of
thisis orthogonal to the issue of buffer cache spoiling in<br /> > PostgreSQL itself. That issue does still exist as
anon-OS issue, but<br /> > we've been discussing in detail the specific case of L2 cache effects<br /> > with
specifickernel calls. All of the test results have been<br /> > stand-alone, so we've not done any measurements in
thatarea. I say this<br /> > because you make the point that reducing the working set size of write<br /> >
workloadshas no effect on the L2 cache issue, but ISTM its still<br /> > potentially a cache spoiling issue.<br
/><br/> What I wanted to point out was that (reiterating to avoid requoting),<br /><br />     - My test was simply to
demonstratethat the observed performance<br />       difference with VACUUM was caused by whether the size of the<br />
     user buffer caused L2 thrashing.<br /><br />     - In general, application should reduce the size of the working
set<br/>       to reduce the penalty of TLB misses and cache misses.<br /><br />     - If the application access
patternmeets the NTA trigger condition,<br />       the benefit of reducing the working set size will be much
smaller.<br/><br /> Whatever I said is probably orthogonal to the buffer cache issue you<br /> guys have been
discussing,but I haven't read all the email exchange<br /> on the subject.<br /><br /> Thanks,<br /> Sherry<br /> --<br
/>Sherry Moore, Solaris Kernel Development        <a
href="http://blogs.sun.com/sherrym">http://blogs.sun.com/sherrym</a><br/><br /></font>