On 2020/6/16 22:57, Marc Smith wrote:

Hi,

I'm using bcache in Linux 5.4.45 and have been doing a number of
experiments, and tuning some of the knobs in bcache. I have a very
small cache device (~16 GiB) and I'm trying to make full use of it w/
bcache. I've increased the two module parameters to their maximum
values:
bch_cutoff_writeback=70
bch_cutoff_writeback_sync=90

These two parameters are only for experimental purpose for people who
want to research bcache writeback bahavior, I don't recommend/support to
change the default value in meaningful deployment. A large number may
cause unpredictable behavior e.g. deadlock or I/O hang. If you decide to
change these values in your environment, you have to take the risk for
the above negative situation.

This certainly helps me allow more dirty data than what the defaults
are set to. But a couple other followup questions:
- Any additional recommended tuning/settings for small cache devices?

Do not change the default values in your deployment.

- Is the soft threshold for dirty writeback data 70% so there is
always room for metadata on the cache device? Dangerous to try and
recompile with larger maximums?

It is dangerous. People required such configurable value for research
and study, it may cause deadlock if there is no room to allocate meta
data. Setting {70, 90} is higher probably to trigger such deadlock.

- I'm still studying the code, but so far I don't see this, and wanted
to confirm that: The writeback thread doesn't look at congestion on
the backing device when flushing out data (and say pausing the
writeback thread as needed)? For spinning media, if lots of latency
sensitive reads are going directly to the backing device, and we're
flushing a lot of data from cache to backing, that hurts.

This is quite tricky, the writeback I/O rate is controlled by a PD
controller, when there are more regular I/Os coming, the writeback I/O
will reduce to a minimum rate. But this is a try best effort, no real
time throttle guaranteed.

If you want to see in your workload which bch_cutoff_writeback or
bch_cutoff_writeback_sync may finally hang your system, it is OK to
change the default value for a research purpose. Otherwise please use
the default value. I only look into related bug for the default value.

Coly Li