On Mon, 3 Jul 2017, tang.junhui@zte.com.cn wrote:

Hello Eric, Coly

quoted

So usually it takes 1.4s, as much as 7s on our systems.  Average frequency
is almost an hour.   Can GC just be triggered more frequently?  Say, once
every 5min?  Is that configurable?

GC is triggered by writing c->sb.bucket_size * c->nbuckets / 16 cache 
data, or triggered by invalidating when there is not enough free 
buckets. So GC time is not configurable, and I also do not think it is 
usable by triggering GC more frequently, because as debug the code, in 
my test bcache version, I find most time used in btree_gc_mark_node() 
(in the latest bcache version it maybe btree_gc_mark_node() and 
btree_gc_count_keys()), They are all memory operations, can we optimize 
it?

Perhaps.  What is the total lock time that prevents IO?  Can you note 
those below?


--
Eric Wheeler

test result：

Jul  3 13:38:27 ceph192-9-9-153 kernel: [10541.541876] gc trigged by sectors_to_gc
Jul  3 13:38:27 ceph192-9-9-153 kernel: [10541.544372] bch_gc_thread works
Jul  3 13:38:27 ceph192-9-9-153 kernel: [10541.569479] gc begin btree_root
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.883089] add cl ffff880458627b18 to wait:ffff8804583237f0
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.884319] journal_write_root with journal_write_unlocked
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.885522] in journal_write_unlocked_root
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.886770] bch_btree_set_root_gc closure_sync wait cl:
ffff880458627b18
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.886852] journal_write_done_root wake up wait: ffff8804583237f0
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.889190] bch_btree_set_root_gc closure_sync wait cl:
ffff880458627b18 end
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.892783] gc btree_root over, begin bch_btree_gc_finish
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.895303] mark_node: 7203 times, 7074 ms; btree_alloc: 0 times, 0
ms; coalse: 7203 times, 0 ms; write1: 7202 times, 80 ms; write2: 1 times, 0 ms; sort_node: 1 times, 1 ms
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.926504] gc bch_btree_gc_finish over, wake_up_allocators
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.928720] bch_moving_gc over, aftre gc, available: 4399506,
nbuckets:6104768
Jul  3 13:38:34 ceph192-9-9-153 kernel: [10548.930144] bch_gc_thread works over
I am very anxious about this question, any comment would be valuable.

Regards
Tang Junhui





发件人:         Eric Wheeler [off-list ref]
收件人:         Coly Li [off-list ref],
抄送:        tang.junhui@zte.com.cn, kent.overstreet@gmail.com, linux-bcache@vger.kernel.org
日期:         2017/06/28 08:00
主题:        Re: Question about gc time

_________________________________________________________________________________________________________________



On Wed, 28 Jun 2017, Coly Li wrote:

quoted

On 2017/6/27 下午8:04, tang.junhui@zte.com.cn wrote:

quoted

Hello Eric, Coly,

I use a 1400G SSD device a bcache cache device,
and attach with 10 back-end devices,
and run random small write IOs,
when gc works, It takes about 15 seconds,
and the up layer application IOs was suspended at this time,
How could we bear such a long time IO stopping?
Is there any way we can avoid this problem?

I am very anxious about this question, any comment would be valuable.

I encounter same situation too.
Hmm, I assume there are some locking issue here, to prevent application
to send request and insert keys in LSM tree, no matter in writeback or
writethrough mode. This is a lazy and fast response, I need to check the
code then provide an accurate reply :-)

What controls the frequency?

On our system I noticed this:

]# tail /sys/block/bcache0/bcache/cache/internal/*gc*

==> /sys/block/bcache0/bcache/cache/internal/btree_gc_average_duration_ms <==
1455

==> /sys/block/bcache0/bcache/cache/internal/btree_gc_average_frequency_sec <==
3521

==> /sys/block/bcache0/bcache/cache/internal/btree_gc_max_duration_ms <==
7036


So usually it takes 1.4s, as much as 7s on our systems.  Average frequency
is almost an hour.   Can GC just be triggered more frequently?  Say, once
every 5min?  Is that configurable?

-Eric

quoted

--
Coly Li
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html