hogthreshold too coarse adjustment
Brought to you by:
bartoldeman
Menu
▾
▴
#531 hogthreshold too coarse adjustment
playing with actual dosemu-devel, it seems as Hogthreshold setting is too coarse. That are approximate (measured vith 'top' utility) CPU load values depending on the hogthreshold value:
HGT CPU% dosemu threads load %
0 147 98 + 48 + 0.3
1 2.7 1.7 + 0.7 + 0.3
2 43 28 + 14 + 0.3
3 80 54 + 24 + 0.3
5 115 75 + 35 + 0.3
10 125 80 + 40 + 0.3
(regards third column: it seems dosemu has active three thread, these three numbers are percentage of load of each)
Thus it seems as only applicable hogthreshold value is 1, all others are causing too high CPU load. Somewhere in doc recommended hogtreshold as half of CPU bogomips (me has ~ 5400) is unrealistic.
This was observerd on C2Duo E8200@2.66GHz/4GB RAM machine, Fedora 19 i686, dosemu in real CPU vm86 mode, in X window; FreeDOS without any DOS apps, it only show 'C:>' prompt.
If you update from git and produce the
-D6+g log, you'll see the messages there,
"sleep requested by <name>"
By the <name> you can find in sources of
the call to idle() function of dosemu. By
lowering the second argument of the call,
you can make it smoother wrt hogthreshold
setting.</name></name>
Darn, SF eats symbols.
The message would read as
"sleep requested by <name;>"
and by that name you can find the
caller in a source.
I tried git 687.g2f988a6 version. Regarding to CPU load with this version, now I got these hogthreshold/CPU load results:
which is now better - it seems because second thread now almost does not burden the CPU, and first thred burden it less.
With your recommended debug settings, 'grep "sleep" debug.log' give (with '$_hogthreshold = (7)' =~ 77% CPU load):
In all cases logs contains only 'sleep requested by int28' record.
And now I do not understand what I should do, what I should search in dosemu sources or what 'lowering the second argument of the call' mean.
Thanks.
In int.c find string idle(0, 50, 0, "int28");
Second argument is 50.
Try fewer.
I did several tests for different second parameter values (original 50, 10, 2, and 1) and for different hogthreshold values (0,1,2,5,10,100). Tests were made tvice, once for default basic debug ('$_debug = "-a+cw"', this produces ~3.5 kB debug.log), the second time for (recommended by you) extended debug ('$_debug = "-a+6cwg"', this produce ~550 MB debug.log - here I can see 'sleep requested by ...' - in tests results is number of their occurrences). All tests only start FreeDOS and took cca 30 seconds (autoexec.bat at its end contain 'choice /t:y,29 подожди 29 сек' and 'exitemu') and was startes with command '/usr/bin/time -o dosemu-load.lst dosemu.bin -X -p'.
Please see at this results, You will interpret they better than I. What seems interesting for me:
when hogthreshold=0, in debug.log are no 'sleep requested by ...' records
when hogthreshold=1, in debug.log are 'sleep requested by int2f_idle_magic' records and no 'sleep requested by int28' records
for other hogthreshold values, there are only 'sleep requested by int28' records; as hoghthreshold increases, their number decreases.
even 'idle(0, 1, 0, "int28")' (second parameter is 1 instead original value 50) in 'src/base/async/int.c' work well with low cpu load (change it?)
in dosemu docs somehere recommended hogthreshold setting as half of machine bogomips value seems as unrealistic, this value should be much smaller.
Tests results:
10 looks most plausible from your figures.
Docs are outdated; in fact, for many years
only hogthreshold=1 was tuned with some care.
1 and 0 are the expected values, the rest
should be rarely used.
Hi both,
Interestingly I saw this old commit in 1.2 release branch which suggests that hogthreshold might be negative in the future! Not sure if it ever got implemented, or what the semantics might be.
IIRC there was some discussion about an
unconditional sleeps, aka cpu slowdown.
Maybe it was supposed to be controlled
with the negative hogthreshold values,
but it was never implemented.
dosbox is much better for slowdown things.