I've got a problem with these variables in freelist.c:

static int		strategy_cdb_found;
static int		strategy_cdb_replace;
static int		strategy_get_from;

Why are these per-backend?  Shouldn't they be in shared state?

			regards, tom lane

Mon, 19 Apr 2004 12:46:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Why are these ARC variables per-backend?
Tom Lane wrote:

> I've got a problem with these variables in freelist.c:
> 
> static int		strategy_cdb_found;
> static int		strategy_cdb_replace;

These two most definitely are per backend because they hold status 
information about the blocks this backend specifically is mucking with. 
If it all would be in one function, they would be local variables.

> static int		strategy_get_from;

This one is questionable. The point of it is to steer the T1/T2 list 
sizes towards the goal of the strategy (T1_target). It doesn't matter 
much if this is off by one every now and then, it will be corrected at 
the next buffer eviction ... or the one after that.


Jan

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


Mon, 19 Apr 2004 13:39:14 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Why are these ARC variables per-backend?
Jan Wieck <JanWieck@Yahoo.com> writes:
> Tom Lane wrote:
>> I've got a problem with these variables in freelist.c:
>> 
>> static int		strategy_cdb_found;
>> static int		strategy_cdb_replace;

> These two most definitely are per backend because they hold status 
> information about the blocks this backend specifically is mucking with. 
> If it all would be in one function, they would be local variables.

Would you object if I made 'em actual local variables?  This would
clutter the strategy API slightly since the vars would have to be passed
out of some routines and into others, but I think it would be logically
cleaner.  (In the back of my mind is the idea to support two instances
of the ARC datastructure, one for global and one for local buffers, so
minimizing the number of static variables is a prerequisite.)
	
>> static int		strategy_get_from;

> This one is questionable. The point of it is to steer the T1/T2 list 
> sizes towards the goal of the strategy (T1_target). It doesn't matter 
> much if this is off by one every now and then, it will be corrected at 
> the next buffer eviction ... or the one after that.

Why do we have it at all?  Seems like it would be at least as good to
make the T1-or-T2 decision in StrategyGetBuffer, rather than earlier.

			regards, tom lane

Mon, 19 Apr 2004 14:58:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Why are these ARC variables per-backend? 
Tom Lane wrote:

> Jan Wieck <JanWieck@Yahoo.com> writes:
>> Tom Lane wrote:
>>> I've got a problem with these variables in freelist.c:
>>> 
>>> static int		strategy_cdb_found;
>>> static int		strategy_cdb_replace;
> 
>> These two most definitely are per backend because they hold status 
>> information about the blocks this backend specifically is mucking with. 
>> If it all would be in one function, they would be local variables.
> 
> Would you object if I made 'em actual local variables?  This would
> clutter the strategy API slightly since the vars would have to be passed
> out of some routines and into others, but I think it would be logically
> cleaner.  (In the back of my mind is the idea to support two instances
> of the ARC datastructure, one for global and one for local buffers, so
> minimizing the number of static variables is a prerequisite.)

Good idea.

> 	
>>> static int		strategy_get_from;
> 
>> This one is questionable. The point of it is to steer the T1/T2 list 
>> sizes towards the goal of the strategy (T1_target). It doesn't matter 
>> much if this is off by one every now and then, it will be corrected at 
>> the next buffer eviction ... or the one after that.
> 
> Why do we have it at all?  Seems like it would be at least as good to
> make the T1-or-T2 decision in StrategyGetBuffer, rather than earlier.

If it'd be possible. The problem is that it can get called multiple 
times during one logical buffer lookup/fault cycle. Because of the 
possible IO, which is done in the caller of the strategy, this would 
screw up the decision process about the queue sizes.

The original ARC logic was built on a single process/thread model, where 
you do the IO just in the middle of the decision process. With our 
buffer manager who's now calling the strategy logic this needs a few 
status switches.


Jan

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


Mon, 19 Apr 2004 15:16:21 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Why are these ARC variables per-backend?
Jan Wieck <JanWieck@Yahoo.com> writes:
> Tom Lane wrote:
>> Why do we have it at all?  Seems like it would be at least as good to
>> make the T1-or-T2 decision in StrategyGetBuffer, rather than earlier.

> If it'd be possible. The problem is that it can get called multiple 
> times during one logical buffer lookup/fault cycle. Because of the 
> possible IO, which is done in the caller of the strategy, this would 
> screw up the decision process about the queue sizes.

How so?  It seems like postponing the decision about which queue to take
from couldn't make the behavior worse; if anything it would help to
track T1target more closely.

			regards, tom lane

Mon, 19 Apr 2004 15:21:35 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Why are these ARC variables per-backend? 
On Mon, Apr 19, 2004 at 02:58:11PM -0400, Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > Tom Lane wrote:
> >> I've got a problem with these variables in freelist.c:
> >> 
> >> static int		strategy_cdb_found;
> >> static int		strategy_cdb_replace;
> 
> > These two most definitely are per backend because they hold status 
> > information about the blocks this backend specifically is mucking with. 
> > If it all would be in one function, they would be local variables.
> 
> Would you object if I made 'em actual local variables?  This would
> clutter the strategy API slightly since the vars would have to be passed
> out of some routines and into others, but I think it would be logically
> cleaner.  (In the back of my mind is the idea to support two instances
> of the ARC datastructure, one for global and one for local buffers, so
> minimizing the number of static variables is a prerequisite.)

I am not sure what changes are in store with the bufmgr locking, but
the concurrency could also benefit from having multiple buffer queues.
This would allow the contention for the locks to be further reduced.
The change to a local variable would also enable that change.

Ken Marshall


Mon, 19 Apr 2004 14:47:45 -0500
Kenneth Marshall <ktm@it.is.rice.edu>
Re: Why are these ARC variables per-backend?