Re: checkpointer continuous flushing - V18

Hello Andres,

>> Now I cannot see how having one context per table space would have a
>> significant negative performance impact.
>
> The 'dirty data' etc. limits are global, not per block device. By having
> several contexts with unflushed dirty data the total amount of dirty
> data in the kernel increases.

Possibly, but how much?  Do you have experimental data to back up that 
this is really an issue?

We are talking about 32 (context size) * #table spaces * 8KB buffers = 4MB 
of dirty buffers to manage for 16 table spaces, I do not see that as a 
major issue for the kernel.

> Thus you're more likely to see stalls by the kernel moving pages into 
> writeback.

I do not see the above data having a 30% negative impact on tps, given the 
quite small amount of data under discussion, and switching to random IOs 
cost so much that it must really be avoided.

Without further experimental data, I still think that the one context per 
table space is the reasonnable choice.

-- 
Fabien.