> Il giorno 13 dic 2018, alle ore 17:53, stan <stanl-fedorau...@vfemail.net> ha > scritto: > > On Thu, 13 Dec 2018 13:42:24 +0100 > Paolo Valente <paolo.vale...@linaro.org> wrote: > >> To test the behavior of your system, why don't you check, e.g., how >> long it takes to start an application while there is some background >> I/O? >> >> A super quick way to do this is >> >> git clone https://github.com/Algodev-github/S >> cd S/comm_startup_lat >> sudo ./comm_startup_lat.sh <scheduler-you-want-to-test> 5 5 seq 3 >> "replay-startup-io gnometerm" >> >> The last command line >> - starts the reading of 5 files plus the writing of 5 other files >> - replays, for three times, the I/O that gnome terminal does while; >> starting up (if you want I can tell you how to change the last >> command line so as to execute the original application, but you would >> get the same results); >> - for each attempt, measures how long this start-up I/O takes to >> complete. > > Just a note: I would feel a lot more comfortable with this utility if > it didn't have to run as root. Paranoia. Could you add the > functionality that if it is run as a normal user, it tests the I/O > scheduling scheme currently enabled. That is, it checks if it is > running as root. If it isn't, it just uses whatever I/O scheduler is > currently set, ignoring any parameter on the command line. Running as > root, it behaves exactly as it does now. > > The user would be responsible for issuing the > > echo <scheduler-you-want-to-test> > > /sys/block/<device-you-want-to-test>/queue/scheduler > > as root if they wanted to run as a normal user.
I do agree with your point, and I already tried to make this run as non root. The actual problem is not the scheduler switch, but the need to drop caches before every start-up attempt. Without that, only the first attempt might be reliable, in case data are not already in the cache even at the first iteration. To drop caches, it seems necessary to be root. Any suggestion to work around this issue would super welcome! Thanks, Paolo > _______________________________________________ > kernel mailing list -- ker...@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/ker...@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
