On Mon, 2020-12-07 at 19:35 +0100, Greg KH wrote: > On Mon, Dec 07, 2020 at 06:26:03PM +0000, Christoph Hellwig wrote: > > On Mon, Dec 07, 2020 at 07:23:12PM +0100, Greg KH wrote: > > > What "real workload" test can be run on this to help show if it > > > is useful or not? These vendors seem to think it helps for some > > > reason, otherwise they wouldn't have added it to their silicon :) > > > > > > Should they run fio? If so, any hints on a config that would be > > > good to show any performance increases? > > > > A real actual workload that matters. Then again that was Martins > > request to even justify it. I don't think the broken addressing > > that breaks a whole in the SCSI addressing has absolutely not > > business being supported in Linux ever. The vendors should have > > thought about the design before committing transistors to something > > that fundamentally does not make sense. Actually, that's not the way it works: vendors add commands because standards mandate. That's why people who want weird commands go and join standard committees. Unfortunately this means that a lot of the commands the standard mandates end up not being very useful in practice. For instance in SCSI we really only implement a fraction of the commands in the standard. In this case, the industry already tried a very similar approach with GEN 1 hybrid drives and it turned into a complete disaster, which is why the mode became optional in shingle drives and much better modes, which didn't have the huge shared state problem, superseded it. Plus truncating the LBA of a READ 16 to 4 bytes is asking for capacity problems down the line, so even the actual implementation seems to be problematic. All in all, this looks like a short term fix which will go away when the drive capacity improves and thus all the effort changing the driver will eventually be wasted. > So "time to boot an android system with this enabled and disabled" > would be a valid workload, right? I'm guessing that's what the > vendors here actually care about, otherwise there is no real stress- > test on a UFS system that I know of. Um, does it? I don't believe even the UFS people have claimed this. The problem is that HPB creates a shared state between the driver and the device. That shared state has to be populated, which has to happen at start of day, so it's entirely unclear if this is a win or a slow down for boot. James
