Skip to content

Commit

Permalink
Now supporting Rust
Browse files Browse the repository at this point in the history
  • Loading branch information
K9spud LLC committed Oct 2, 2021
1 parent b00c861 commit 0ee7494
Showing 1 changed file with 7 additions and 23 deletions.
30 changes: 7 additions & 23 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,31 +15,15 @@ By keeping the processes pipelined in this fashion, we can keep all 4 cores of t

As a side benefit, this tool also ends up automatically throttling back emerge builds whenever you're busy using your computer for other tasks. Sure, your builds will take longer to complete, but at least they won't completely fail or prevent you from being able to use your computer at all, like they would otherwise.

What's New in v1.0.7
What's New in v1.0.8
====================

Ran into a deadlocked build of Chromium where a couple "aarch64-unknown"
processes were in the "D" state (waiting on disk I/O), but were
actually apparently waiting on the other pair of stopped "aarch64-unknown"
processes to finish doing whatever.

Added a workaround so that "Draining The Swamp" will not count
"aarch64-unknown" processes in the "D" state towards the "allowed to run"
process count. This is kind of a hack, but it's working for me so far.

Finished compiling Chromium 90.0.4427.5 after five days or so on my RPi4
with 4GB RAM, zswap enabled, and 4GB of swap space on an external USB HDD
partition. I did, however, spend a bit of time during those 5 days at "-1"
process limiting, so that I could safely browse the web or play MegaGlest
while the build continued cranking along in the background... Yay for
dynamic adjustment of build parallelism!

Changed the "ps" external process starting code to wait indefinitely for "ps"
to finish. Previously the QProcess class was defaulting to a 30 second
time-out, which ordinarily is plenty of time for "ps" to finish executing,
but I guess if your system is heavily swamped, it might actually take longer.
This might solve sibercat's report of getting "QProcess::start: Process is
already running" warning messages.
This release provides support for throttling Rust projects. It turns out,
Rust makes use of multiple CPU cores through threads rather than forking
separate processes. Top and "ps" by default report at the process level, thus
hiding all the threads from Draining The Swamp. We now call "ps" with the
right command line options to report each thread, so now Rust should work
nicely.

Requirements
============
Expand Down

0 comments on commit 0ee7494

Please sign in to comment.