On Fri, Feb 20, 2004 at 05:26:46AM -0500, Neil Conway wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>Kenneth Marshall would like me to post this:
> >> I agree that in order to manage today's large memory machines, we
> >> need to have less contention in our buffer management strategies.
> >
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>>Kenneth Marshall would like me to post this:
>> I agree that in order to manage today's large memory machines, we
>> need to have less contention in our buffer management strategies.
>> The two main main choke points are in the buffer hash table routines
>Kenneth Marshall would like me to post this:
> I agree that in order to manage today's large memory machines, we
> need to have less contention in our buffer management strategies.
> The two main main choke points are in the buffer hash table routines
> and in the buffer management linked lists. U
>Tom Lane
> Manfred's numbers definitely say that we need to find a way to break
> down the BufMgrLock into multiple finer-grain locks. We already have
> all those per-buffer LWLocks, but I don't see how to apply those to
> the problem of managing the global lookup and replacement
datastructures.
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> 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
Manfred Spraul <[EMAIL PROTECTED]> 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,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> If we can't eliminate the global lock, and we reduce its duration?
It'd be a big win even if we could just arrange that ReadBuffer and
ReleaseBuffer don't *both* grab the same global lock.
Can we logically separate the buffer lookup hashtable from the f
Jan Wieck wrote:
Moving the Cache Directory Block (cdb) on a hit to the MRU position of
the appropriate queue "is the bookkeeping" of this strategy. The whole
algorithm is based on it, and I don't see yet how to avoid that without
opening a huge can of worms that look like deadlocks. But I'll thin
Jan Wieck wrote:
> Manfred Spraul wrote:
> > Bruce Momjian wrote:
> >
> >>>Anyone see an attack path here?
> >>>
> >>>
> >>
> >>Should we have one lock per hash bucket rather than one for the entire
> >>hash?
> >>
> >>
> > That's the simple part. The problem is the aging strategy: we need a
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
>>>Anyone see an attack path here?
>>>
>>>
>>
>>Should we have one lock per hash bucket rather than one for the entire
>>hash?
>>
>>
> That's the simple part. The problem is the aging strategy: we need a
> strategy that doesn't rely on a global
Bruce Momjian wrote:
>>Anyone see an attack path here?
>>
>>
>
>Should we have one lock per hash bucket rather than one for the entire
>hash?
>
>
That's the simple part. The problem is the aging strategy: we need a
strategy that doesn't rely on a global list that's updated after every
lookup
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> >> That's irrelevant to the problem, though. Unless the ARC code uses data
> >> structures that are more amenable to localized locking than the old
> >> global buffer freelist. (Jan?)
>
> > the strategy itself does no locking at all. Like
Jan Wieck <[EMAIL PROTECTED]> writes:
>> That's irrelevant to the problem, though. Unless the ARC code uses data
>> structures that are more amenable to localized locking than the old
>> global buffer freelist. (Jan?)
> the strategy itself does no locking at all. Like the old LRU code it
> simp
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Manfred Spraul wrote:
I remember there were patches that tried other algorithms instead of the
simple LRU for the buffer manager. Has anyone tried to change the
locking of the buffer manager?
CVS HEAD already has an Adap
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Manfred Spraul wrote:
>> I remember there were patches that tried other algorithms instead of the
>> simple LRU for the buffer manager. Has anyone tried to change the
>> locking of the buffer manager?
> CVS HEAD already has an Adaptive Replacement Cach
[EMAIL PROTECTED] wrote:
Hi Manfred,
I'm using unixware 7 but couldn't compile your source with native cc, I
had to compile it with gcc.
here are the results:
Thanks. The test app compares the time needed for three different short
loops: a loop with six empty function calls, a loop with six f
Hi Manfred,
I'm using unixware 7 but couldn't compile your source with native cc, I
had to compile it with gcc.
here are the results:
Script started on Sat Dec 27 17:50:49 2003
/tmp 17:50:50: ./a.out
MOVETEST called by non-superuser, running with normal priority.
zerotest: -1073736628 tick
17 matches
Mail list logo
