Re: [RFC][PATCH] bcache: ver 3

[Egon Alter]

I'm wondering if this is similar to the "Cleancache" patches send a few days 
before. 

Could bcache provide a (block-dev) backend to cleancache? Also there is fs-
cache (for networks-fs only currently). Can these caches be combined somehow?

Egon

Kent Overstreet:
> The core code is getting close to stable and feature complete. Garbage
> collection is done, and locking is mostly done (I'm not refcounting data
> buckets yet, and it does need to be stared at a whole lot more but it
> passes lockdep and seems to be working).
> 
> Basic bucket priority calculation is done (right now it acts as an LRU);
> you can fill the cache up and everything works like it ought to. And,
> I've yet to see it return bad data; I think it's not all that far off
> from being useful.
> 
> The one thing that has me at a loss right now is the performance isn't
> where it should be, and for no obvious reason. The problem is most
> succinctly demonstrated thusly:
> 
> With cache, no cache misses:
> root@utumno:~# mount -o ro /dev/sdb /mnt/
> root@utumno:~# cd /mnt/
> root@utumno:/mnt# time find > /dev/null
> 
>  real	0m29.618s
>  user	0m0.000s
>  sys	0m0.840s
> 
> No cache device:
> root@utumno:~# mount -o ro /dev/sdb /mnt/
> root@utumno:~# cd /mnt/
> root@utumno:/mnt# time find > /dev/null
> 
> real	0m1.597s
> user	0m0.050s
> sys	0m1.240s
> 
> This is a vm, so the wall clock time in the latter case doesn't mean
> much, it's all in the hosts's cache. But the former case is bewildering;
> the cache device lives on a tmpfs so it shouldn't be waiting on IO, and
> cpu time is less than the uncached case. Clearly it's waiting on
> something, but I haven't been able to figure out what the heck to trace;
> there's no lock contention, blktrace shows nothing unexpected, I keep
> running into dead ends. Any pointers here would be much appreciated.
> 
> Besides that, there shouldn't be anything complex left before I add
> write support, and that should be pretty straightforward too.
> 
> This patch does have some changes to the generic bio code for completion
> of split bios, I'm going to split it out and submit it seperately after
> I've gone over it more and it's actually been tested.
> 
> Any comments/review much appreciated.
> [patch sniped]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/