It would be great if rtorrentd's init script would support adjusting the nice and ionice values of the rtorrent process. The nice levels should be applied to the rtorrent process, not screen as a whole.
Created attachment 218661 [details] Updated init script that should support nice/ionice levels
Created attachment 218663 [details] Updated default conf file
I have modified the init script to set the nice/ionice levels via start-stop-daemon. However, this approach sets them at the screen level, which is suboptimal. nice/ionice could be invoked by screen, although a couple of searches on the web found comments about ionice potentially misbehaving. slocate's cron script invokes ionice for its own process as a work around.
This package uses start-stop-daemon so it likely that you don't need to modify anything. Take a look at man start-stop-daemon: there is SSD_NICELEVEL variable that modifies nice level, and ionice level is binded with nice... I think this bug is invalid.
Even if you use SSD_NICELEVEL, you still need to modify the init script to set the ionice class/priority. (see attached files) If I mentionned setting nice/ionice after screen that's because if the user attaches to the rtorrentd screen to check up on rtorrent then creates a new window (C-a C-c) to handle some other business (like moving files around, which I assume is a common occurence for P2P users) the user might not be aware that what they are running is running under a heavy nice level or a bad io class. It makes sense to run P2P under the "idle" prio class, but if you try to run emerge -DNua world under the idle prio class, it can take ten minutes before it even offers you a list of update. With that said, setting nice/ionice on screen is perfectly acceptable, all things considered.
(In reply to comment #5) > Even if you use SSD_NICELEVEL, you still need to modify the init script to set > the ionice class/priority. (see attached files) Are there any reasons to do that? CFQ scheduler does that automatically and for other schedulers... If this is really important then it's better to move this logic to openrc instead of adding this all possbile init scripts. > If I mentionned setting nice/ionice after screen that's because if the user > attaches to the rtorrentd screen to check up on rtorrent then creates a new > window (C-a C-c) to handle some other business (like moving files around, which > I assume is a common occurence for P2P users) the user might not be aware that > what they are running is running under a heavy nice level or a bad io class. Suggested patch runs screen with different ionice, and this problem is not solved there. Or what do I miss? > It makes sense to run P2P under the "idle" prio class, but if you try to run > emerge -DNua world under the idle prio class, it can take ten minutes before > it even offers you a list of update. init script runs screen from different user... So I don't any reason to run emerge or any other activity from there. > With that said, setting nice/ionice on screen is perfectly acceptable, all > things considered. Don't get me wrong. I agree here, but I think that more general solution should be borrowed (that can be used in all init scripts that use start-stop-daemon) instead of patching separate init script for this functionality.
(In reply to comment #6) > Are there any reasons to do that? CFQ scheduler does that automatically and for > other schedulers... If this is really important then it's better to move this > logic to openrc instead of adding this all possbile init scripts. I'm afraid I don't know I/O schedulers well enough to answer the part about CFQ. I haven't formally benchmarked it, but I started running rtorrent under the "idle" prio class after seeing it slow down other apps (emerge jobs, starting up a new application, etc..) during its most I/O-heavy operations, such as rehashing a torrent, which can require to read a few GB's off the disk. Under the default prio class (best-effort) other apps would feel less responsive in those situations, whereas with the idle prio class I wouldn't notice any change. > Suggested patch runs screen with different ionice, and this problem is not > solved there. Or what do I miss? Nothing. The init script I have attached does apply the io/nice settings on screen because start-stop-daemon seems like the cleaner, safer way to operate. Ideally, I would have liked to restrict the niceing to rtorrent only but I got cold feet after reading somewhere (I'm sorry I didn't save the link :\) about some potential issue with ionice run as a non-root user.
As rtorrent supports daemon mode from 0.9.7, we can just use SSD_NICELEVEL the usual way once support is implemented in the ebuild, making further patches unnecessary. It hasn't been implemented in the ebuild yet, but should be after some further bugs are resolved.
