On 5/8/18, Francesco Porro <frapox@xxxxxxxxx> wrote: > In data martedì 8 maggio 2018 21:08:35 CEST, Carsten Mattner ha scritto: >> Linux block layer's writeback system was supposed to fix this, >> but I've also noticed that the mechanism isn't perfect and >> you can still have a "hanging" application when doing the >> infamous USB-to-USB transfer that kills the VM subsystem. >> >> Another way I can reproduce it is when there SSD-to-thumb-drive >> and you decide to some disk activity, too. >> >> https://lwn.net/Articles/682582/ >> >> The problem is that VM gets pressured a lot and the whole >> construct fails in a way, while working as designed, >> manifesting as hanging programs. > > Ok, but I'm talking about HDD on Sata bus. No Usb-to-usb transfers > involved. And, as said before, I've altready tweaked the > vm.dirty{writeback,background_ratio} to partialy word around this, > either on Debian or Arch linux. It's easier to trigger with slow devices but ultimately the same issue of block layer and vm subsystem getting overwhelmed. >> First, to confirm, if you manage to run the indexer like >> you would `ionice -c idle <the-indexer>`, and it shows >> less hangs, you know the issue is unfair I/O queuing. > > The indexer's process autostarts and rapidly kills himself in a bunch of > seconds... its impossible to renice the process, however I saw (by > Ksysguard) it's always 19 as nice value... meaning high fairness both > for the CPU, and I think for the IO too. > > >> You can compare the block layer kernel configuration of >> Debian vs Arch. > > Sorry, how to? Which are the keyword for searching? On both systems there should be /proc/config.gz of the running kernel. If you have a suspicion which kernel option is responsible, you can check if it's different between Arch and Debian. >> You can try deadline or bfq schedulers. One is dead simple >> and the other optimizes for desktop responsiveness. > > As a last chance, I'll look into these alternatives schedulers. But now, > either Debian or Arch are using the same one: Cfq. So I don't think this > is the cause of the problem. Sounds true. Is it only that one application or others as well when they cause much I/O?
