Re: [PATCHES] update i386 spinlock for hyperthreading - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: [PATCHES] update i386 spinlock for hyperthreading
Date
Msg-id 3FF1AE0F.1040003@Yahoo.com
Whole thread Raw
In response to Re: [PATCHES] update i386 spinlock for hyperthreading  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

> Manfred Spraul <manfred@colorfullife.com> writes:
>> Are there strategies that do not rely on a global lock? The Linux kernel 
>> uses a lazy LRU with referenced bits: on access, the referenced bit is 
>> set. The freespace logic takes pages from the end of a linked list, and 
>> checks that bit: if it's set, then the page is moved back to the top of 
>> the list. Otherwise it's a candidate for replacement.
> 
> I think this is the same idea as what I was just suggesting: add an
> extra check when looking for a free page, and thereby avoid having to
> lock/update the global datastructure during ReadBuffer.

Hmmmm ... speaking without having done in depth thought on this one:

If there would be an easy way to determine the approximate position of a 
CDB inside the queue, one could just forget about moving it to the MRU 
position if it's in the upper 3rd or so anyway.

The theory of the whole ARC strategy (which is nothing more than four 
LRU's with a twist) is that the access frequency of blocks is reverse 
proportional to their numbers (a few are high frequency used, some are 
medium often requested, the vast majority rather seldom). That means, 
that the buffers in the upper third or quarter of the T1 queue (and 
that's the critical one) are basically circling around each other with 
frequent visitors from the lower regions or other queues.

So if there would be a way to make a good guess on that relative queue 
position, that expensive CDB shuffeling can be avoided often.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



pgsql-hackers by date:

Previous
From: Mark Wong
Date:
Subject: patching PostgreSQL on STP with dbt-2
Next
From: ivan
Date:
Subject: cache in plpgsql