Zeugswetter Andreas DAZ SD <ZeugswetterA@spardat.at> wrote on
15.12.2004, 15:33:16:
>
> > The two alternative algorithms are similar, but have these
> > differences:
> > The former (option (2)) finds a constant number of dirty pages, though
> > has varying search time.
>
> This has the disadvantage of converging against 0 dirty pages.
> A system that has less than maxpages dirty will write every page with
> every bgwriter run.
Yes, that is my issue with that algorithm.... it causes more contention
when there are less dirty pages.
> > The latter (option (3)) has constant search
> > time, yet finds a varying number of dirty pages.
>
> This might have the disadvantage of either leaving too much for the
> checkpoint or writing too many dirty pages in one run. Is writing a lot
> in one run actually a problem though ? Or does the bgwriter pause
> periodically while writing the pages of one run ?
> If this is expressed in pages it would naturally need to be more than the
> current maxpages (to accomodate for clean pages). The suggested 2% sounded
> way too low for me (that leaves 98% to the checkpoint).
This remains to be seen. We have Mark Kirkwood's test results that show
that the algorithm may work better, but no large scale OSDL run as yet.
My view is that the 2% is misleading. The whole buffer list is like a
conveyor belt moving towards the LRU. It is my *conjecture* that
cleaning the LRU would be sufficient to clean the whole list
eventually. Blocks in the buffer list that always stay near the MRU
would be dirtied again quickly even if you did clean them, so if they
don't reach nearly to the LRU then there is less benefit in cleaning
them. (1%, 2% or 5% would need to be a tunable factor; 2% was the
suggested default)
If the bgwriter writes too often it would get in the way of other work,
so there is clearly an optimum setting for any workload.
> Also I think we are doing too frequent checkpoints with bgwriter in
> place. Every 15-30 minutes should be sufficient, even for benchmarks.
> We need a tuned bgwriter for this though.
Well, yes, you're right. ...but the bug limiting us to 255 files
restricts us there for higher performance situations.
Best Regards, Simon Riggs
