Re: Bug: Buffer cache is not scan resistant

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
Cc: "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Pavan Deolasee" <pavan(at)enterprisedb(dot)com>, "Gavin Sherry" <swm(at)alcove(dot)com(dot)au>, "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Doug Rady" <drady(at)greenplum(dot)com>, "Sherry Moore" <sherry(dot)moore(at)sun(dot)com>
Subject: Re: Bug: Buffer cache is not scan resistant
Date: 2007-03-06 05:29:20
Message-ID: 27070.1173158960@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Luke Lonergan" <llonergan(at)greenplum(dot)com> writes:
> Here's the x86 assembler routine for Solaris:
> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/ia32
> /ml/copy.s
> The actual uiomove routine is a simple wrapper that calls the assembler
> kcopy or xcopyout routines. There are two versions (for Opteron), one that
> uses the NTA instructions that bypass the L2 cache on writing to avoid L2
> cache pollution, and the second writes normally - through the L2 cache.

Hm. If it were bypassing the L2 cache then the hit would be taken when
PG later tries to read the data. This is clearly not what's happening
in the Linux system, but I've not seen any oprofile-equivalent data for
Solaris?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sherry Moore 2007-03-06 05:34:19 Re: Bug: Buffer cache is not scan resistant
Previous Message Tom Lane 2007-03-06 05:18:42 Re: PL/Python warnings in CVS HEAD