On 1/20/24 05:43, Phillip Susi wrote: > Phillip Susi <phill@xxxxxxxxxxxx> writes: > >> The block layer also would need patched to avoid turning a barrier into >> a FLUSH CACHE if the disk is runtime suspended, and also the sync() >> path. Is that even sensible to do? It is true that for all block >> devices, their caches do not need flushed while they are runtime >> suspended? It seems like it may be, but I'm not certain. > > I was trying to do this. I think the right place is in > blkdev_issue_flush(), but apparently bdev->bd_device is not the same > struct device that gets suspended. I can't seem to work out where the > right struct device is to pass to pm_runtime_suspended() and skip the > flush operation. Flush issuing is a lot more complicated than just blkdev_issue_flush(). There is a whole file dedicated to handling flushes (block/blk-flush.c). But that is beside the point, which is that trying to not execute flush is simply completely wrong. Please stop trying. For your case, which is a drive put to sleep with hdparm -Y, only libata is aware that the drive is sleeping. That first needs to change if you want the kernel overall to be able to do anything. As I proposed already, using runtime PM with sleep mode instead of standby would be a good start. Regarding the flushes and other commands you see that are waking up the drive for no *apparent* good reasons, please identify what application/component is issuing these commands and look there to see why the commands are being issued and if that is done with awareness for the device power state. Then we can patch properly instead of trying to "hack". -- Damien Le Moal Western Digital Research
