linux-kernel - Re: [RFC][PATCH] bcache: ver 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 24 Apr 2010 17:47:40 +0200
From:	Egon Alter <egon.alter@....net>
To:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] bcache: ver 3


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@...mno:~# mount -o ro /dev/sdb /mnt/
> root@...mno:~# cd /mnt/
> root@...mno:/mnt# time find > /dev/null
> 
>  real	0m29.618s
>  user	0m0.000s
>  sys	0m0.840s
> 
> No cache device:
> root@...mno:~# mount -o ro /dev/sdb /mnt/
> root@...mno:~# cd /mnt/
> root@...mno:/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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/