-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help debugging performance issue. #1313
Comments
Try something like this:
|
Wow, thanks for the quick response! I tested it and it is much better, and still seems just as responsive as it did before when using it. That's a huge improvement, it seems to use about 8% CPU when idle, which is a lot more acceptable. |
Just to elaborate -- many DOS programs don't care about using 100% CPU when idle, and it wasn't much of an issue at the time they were written. There are some ways however for them to be a bit nicer, the standards are using int28 or int2f/ax=1680 but they are not always used. So DOSEMU implements some heuristics, mainly when the DOS program polls the keyboard or mouse for input. Yours was just a case that wasn't considered yet. |
8% is a bug by itself. |
What do you think about adding a check for the It seems to help performance a bit for me, and I think it's rare to have unsynchronized tsc anymore (I think that was the concern with SMP). |
There were cpus where periodic rdtsc |
This regressed all DR-DOS tests, wow! |
https://travis-ci.com/github/dosemu2/dosemu2/builds/190142718 But now it says "fixed". |
That test set you point to is the cron and is the only time DR-DOS and FreeDOS 1.20 is tested, so the failure is not specific to the commit it ran on, it could be any commit is the last week that broke it. |
Then why it says "fixed" after a new |
OK, last week only you touched mfs |
So the test set is
I can reproduce here and the problem is the test is hitting a timeout. If I run the test by hand it takes a good while but passes. It seems something generally got slower. I'll try to bisect. |
This patch adds delays, so it became |
Or something like |
I started the bisect, I may as well continue just to make sure it really is this patch. |
As you want. :) |
|
OK, you spent an hour bisecting to |
Here's a -D+g log, so you can decide what best to do as I have to go out again now. |
Why not to try |
This tweak allows the DR-DOS tests to complete without timeout on both my machine and Travis. The other int1a subfunctions aren't altered because I have no stimulus to test with. Value suggested by @stsp, see dosemu2#1313 (comment)
Hello, I'm trying to run Lotus Agenda 2.0b in DOSEMU2 in terminal mode. It works perfectly, but uses significant CPU while idle. That's stopping my CPU from entering power saving modes, so was hoping I can fix it.
I have other applications I use under DOSEMU that use barely any resources while not actively using them.
If I use
-D9+D
, I see the log is full of these:I'm not a DOS programmer, do those AH=2A/2C mean Agenda is doing get system time / get system date in some timer interrupt handler?
If I strace the dosemu process, I see it looks like this:
There are lots of calls to
clock_gettime()
, I think that's becauserdtsc
isn't used on SMP systems,config_post_process()
disables it. However, if you have a CPU with invariant/synchronized tsc it should be safe, right?I tried patching the code to allow rdtsc, and it does seem to work okay.
That got rid of the
clock_gettime()
, calls and now it looks like this:I think the
stat()
s must be thelocaltime()
inget_linux_ticks()
checking if the timezone has changed, I can get rid of those by setting the TZ environment variable (e.g.TZ=America/Los_Angeles dosemu -term
).Now it looks like this:
It's a little better, but still using a lot of CPU while idle. Do you have any advice?
Perhaps I can limit how often this timer interrupt fires?
Thanks!
The text was updated successfully, but these errors were encountered: