On Mon, Sep 16, 2024 at 07:19:21PM +0530, Kanchan Joshi wrote: > > Maybe part of the problem is that the API is very confusing. A smal > > part of that is of course that the existing temperature hints already > > have some issues, but this seems to be taking them make it significantly > > worse. > > Can you explain what part is confusing. This is a simple API that takes > type/value pair. Two types (and respective values) are clearly defined > currently, and more can be added in future. I though I outlined that below. > > But if we increase this to a variable number of hints that don't have > > any meaning (and even if that is just the rough order of the temperature > > hints assigned to them), that doesn't really work. We'll need an API > > to check if these stream hints are supported and how many of them, > > otherwise the applications can't make any sensible use of them. > > - Since writes are backward compatible, nothing bad happens if the > passed placement-hint value is not supported. Maybe desired outcome (in > terms of WAF reduction) may not come but that's not a kernel problem > anyway. It's rather about how well application is segregating and how > well device is doing its job. What do you mean with "writes are backward compatible" ? > - Device is perfectly happy to work with numbers (0 to 256 in current > spec) to produce some value (i.e., WAF reduction). Any extra > semantics/abstraction on these numbers only adds to the work without > increasing that value. If any application needs that, it's free to > attach any meaning/semantics to these numbers. If the device (or file system, which really needs to be in control for actual files vs just block devices) does not support all 256 we need to reduce them to less than that. The kernel can help with that a bit if the streams have meanings (collapsing temperature levels that are close), but not at all if they don't have meanings. The application can and thus needs to know the number of separate streams available.
