2017-10-19 18:39 GMT+03:00 David Sterba <dsterba@xxxxxxx>: > On Fri, Sep 29, 2017 at 06:22:00PM +0200, David Sterba wrote: >> On Thu, Sep 28, 2017 at 05:33:35PM +0300, Timofey Titovets wrote: >> > Compile tested, hand tested on live system >> > >> > Change v7 -> v8 >> > - All code moved to compression.c (again) >> > - Heuristic workspaces inmplemented another way >> > i.e. only share logic with compression workspaces >> > - Some style fixes suggested by Devid >> > - Move sampling function from heuristic code >> > (I'm afraid of big functions) >> > - Much more comments and explanations >> >> Thanks for the update, I went through the patches and they looked good >> enough to be put into for-next. I may have more comments about a few >> things, but nothing serious that would hinder testing. > > I did a final pass through the patches and edited comments wehre I was > not able to undrerstand them. Please check the updated patches in [1] if > I did not accidentally change the meaning. I don't see a link [1] in mail, may be you missed it? I look at my patches in for-next branch, and that's not looks like changed, so i assume your link not point at kernel.org %). > I'm about to add the patchset to the main patch pile for 4.15 soon. > Further tuning is possible and such patches will be probably accepted > during the 4.15 development cycle once the as parts have landed. It's > desirable to gather some testing results of heuristic effects on various > data types. So far I've been watching for performance drops only. Just for my information, you compare compress + heuristic with compression force? P.S. Just to sync that we expect from heuristic: it's expected to get some performance drops on easy compressible data, because heuristic not free, but how much this drops? Main reason for heuristic, it's to win cpu/latency cost for bad compressible data. In compare to direct compression. That allow to provide some worst case stable latency/throughput for userspace. P.S.S. I send some emails before, where i show slow paths in heuristic (sort(), ilog2()). So i expect that kernel can see same slow downs on that paths. But i'm don't have enough skills for now, to perform kernel profiling. > In case the heuristic would turn out to cause problems we can't fix > during 4.15 cycle, we can still disable it. This is only a last resort > measure but we need to be prepared. kk Thanks. -- Have a nice day, Timofey. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
