On Thu, Jul 11, 2013 at 09:45:25AM -0400, sheng qiu wrote: > Hi Kent, > > i do not know if this is a problem or i did not understand correctly. > when i enable the copy_gc, at first the gc_moving_threshold is larger > than the bucket size (512KB), I haven't looked at the copy gc code in ages, but if I remember the algorithm I used - the threshold is set based on how many buckets we want to free up, so if most of the buckets are reclaimable threshold > bucket size is what I'd expect. > i guess maybe initially they are set to > 1<<14 -1, after some time, seems all the bucket are set to use all the > sectors it own, which is 1024 in my case. I guess this is because > SET_GC_SECTORS_USED(bucket.size) is called while returning a free > bucket for new allocation. then the gc_moving_threshold became 1024 > (512KB), and no bucket's GC_SECTORS_USED is smaller than this value. > So no gc_moving event at all. > at first, i thought the bcache code would set 0 sectors used for each > new allocated bucket, and then update GC_SECTORS_USED whenever fill > data into the bucket. In that way, we can track how many data are > valid within a bucket. When we allocate a bucket we generally fill it up right away - we don't make it available for GC (the ->pin refcount) until after we're finished writing to it, at which point GC_SECTORS_USED is going to = bucket_size. So that's why the alloc code just sets GC_SECTORS_USED(b, ca->sb.bucket_size) when you allocate it. But then over time, as new writes come in - when those writes are overwriting data that's already in the cache, now GC will notice those buckets aren't full of (live) data anymore. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
