Kent Overstreet <koverstreet@...> writes: > > Man, this is a frustrating issue :) > > I haven't been able to come up with a way of fixing it right without > rewriting a bunch of code. I do have a workaround figured out though > if this is a real issue for you - it'll just increase internal > fragmentation in the btree a bit, but with large btree nodes like you > normally want not enough to matter. > > Though like I said, as long as your workload isn't 100% reads this > shouldn't be an isuse. > Sorry to be away for a few days. I can imagine it is frustrating. I've been looking at the code and it seems pretty tough. I think it would be worthwhile to have this fixed if possible as it does benefit small caches (i.e. 1GB in size) as well. Basically, I made my combination of reads verses writes to be 99 to 1 like you said to do. So 99% of the time, I'm doing a read. When I do this, I never see my IOPS rate get over approximately 45K. Also previously, when I run my test over a 1GB region with 100% reads, once the cache warmed, I would see 0.350ms response time for a read. Once I changed the read/write mixture to 99% reads, the response time went down to 0.150ms. So I would think it would be beneficial to small workloads and large workloads if we could fix this. I'm happy to test this for you or help out in any way possible. Thanks. -brad w. -- 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
