On 17 Feb 2019, Kai Krakow uttered the following: > Hi! > > Am So., 17. Feb. 2019 um 07:22 Uhr schrieb Coly Li <colyli@xxxxxxx>: >> I am open with the ioprio patch, and also I plan to provide it for some >> partners and wait for the response (not do it yet, but on my plan). What Oh good!!! >> I concern is the confused configuration interface, we need to make it >> much simpler. We don't need to check ioprio very accurate, if we can >> find a way to configure it simpler. We need someone work on it, that is it. > > I'm still not sure if we can really simplify it - given that it is > neither complicated nor misleading the way it is now. > > The interface defines just two variables: A lower threshold below > which caching is always skipped, and an upper threshold above which > writeback is always forced. > > The fact that each threshold is made from two values doesn't make it > complicated. It just two octal digits represented as separate decimal > values. Quite. Also, I find the fact that we can configure both the class and priority (and the default) very useful: it means that idle-prio stuff *never* gets cached, but that if you want more normal-prio stuff to not be cached bcause you *know* it is extremely transient you can ask for it with a simple ionice -c 2 -n 7. i.e. the fact that both class and prio are covered seems very desirable to me. The fact that ioprio is what is used seems *ideal* (I think Christoph had objections because he thought it was conflating I/O priority with something unrelated? My memory is fuzzy on that point). Low-iopriority stuff maps precisely to the stuff you aren't likely to want to cache, because it is by definition stuff you don't care about waiting perhaps arbitrarily long for. (I have no opinion on the writeback side of things, since I'm not using that.)
