Opened 2 years ago

Last modified 5 months ago

#13697 new bug

Laggy performance when SMP is enabled on nightly haiku builds

Reported by: addos Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

With the last stable release (alpha 4.1), haiku performs fine.

I started testing the nightlies, and deskbar/tracker seem to miss click events. The activity monitor is jerky. It was suggested that I create a video, which I did.

https://drive.google.com/open?id=0BzncnjBGK7NOeDJYTE9vd2FrbW8

From the syslog, this was output:

KERN: int 219, enabled 1, handled 18128, unhandled 15984 KERN: kernel_x86:apic_timer_interrupt__FPv (0x80158820), data 0x00000000, handled 18127

Not sure if that is the problem. I am attaching the syslog from the system.

I started testing different debug options from the bootloader, and the only thing that seemed to make a difference was to disable smp.

Attachments (6)

syslog (272.0 KB ) - added by addos 2 years ago.
IMAG0534.jpg (4.0 MB ) - added by addos 17 months ago.
IMAG0535.jpg (3.9 MB ) - added by addos 17 months ago.
IMAG0536-2.jpg (1.7 MB ) - added by addos 17 months ago.
syslog-20190527.xz (24.1 KB ) - added by addos 5 months ago.
syslog-20190528.xz (17.0 KB ) - added by addos 5 months ago.
syslog from system1

Change History (47)

by addos, 2 years ago

Attachment: syslog added

comment:1 by addos, 2 years ago

Has a Patch: set

comment:2 by pulkomandy, 2 years ago

Has a Patch: unset

comment:3 by addos, 22 months ago

Is there any update on this? Is there anything else I can provide to help troubleshoot what is happening? Are there any debug builds I could run that could give you more information?

comment:4 by addos, 17 months ago

Does anyone have any ideas on how to troubleshoot this?

comment:5 by diver, 17 months ago

Drop into KDL via kernel_debugger command and run ints.

by addos, 17 months ago

Attachment: IMAG0534.jpg added

comment:6 by addos, 17 months ago

Attached a new screenshot of ints output from kernel_debugger

comment:7 by korli, 17 months ago

Could you try with a nightly hrev51974 or newer? (avoid updates because of gcc7 changes)

comment:8 by addos, 17 months ago

Here is a screenshot from 51976

by addos, 17 months ago

Attachment: IMAG0535.jpg added

comment:9 by korli, 17 months ago

The performance is the same?

comment:10 by addos, 17 months ago

Yes, very very choppy.

comment:11 by addos, 17 months ago

I can make a video showing choppiness if you want to see it?

comment:12 by korli, 17 months ago

you could try to disable the ipro1000 driver.

comment:13 by addos, 17 months ago

How should I disable the driver?

comment:15 by addos, 17 months ago

I disabled the broadcom, ipro1000 driver, hda driver. But none of those disables made it any less choppy. I dropped to kernel_debugger and did ints again with all of those disabled.

by addos, 17 months ago

Attachment: IMAG0536-2.jpg added

comment:16 by korli, 17 months ago

OK thanks. It seems to be related with SMP then. You could try some older nightlies and see when the regression appeared after hrev45141.

comment:17 by diver, 17 months ago

Does disabling SMP in the bootloader fixes choppiness?

comment:18 by addos, 17 months ago

Yes, when I disable SMP it seems like haiku is less choppy.

comment:19 by waddlesplash, 11 months ago

How is this with beta1?

comment:20 by addos, 11 months ago

Hi, I just tested beta1 on this system, and I am still getting the laggy performance. There are periods of time where performance monitor will stop updating, almost like it is skipping frames or something, and then it will have a burst where it does an update. And there are times where I am mousing over items in the deskbar where the screen doesn't refresh. I am not entirely sure how to debug/troubleshoot what the cause is, though.

comment:21 by waddlesplash, 5 months ago

Can you please retest on a recent nightly? The SMP locking changes may have improved this.

comment:22 by waddlesplash, 5 months ago

Component: - GeneralSystem

comment:23 by addos, 5 months ago

Hi, I wanted to say, I just tried nightly build 53159, and the performance does seem significantly better. There are a few pauses, but in general things are much smoother, it is a lot less laggy than it used to be. Now it is at least usable.

comment:24 by addos, 5 months ago

Actually, maybe I take it back. When I disable multiple cores, and drop it down to a single core. I get a lot more responsiveness out of the system as a whole. So even though it might be a bit better, it still is far from perfect. I tried playing video in webpositive from youtube, and can only really play it decently with only a single core enabled. If I have all the cores enabled, it gets really choppy.

comment:25 by waddlesplash, 5 months ago

Can you recheck against alpha4.1? The ticket description you are talking about missing clicks and the like in Tracker/ActivityMonitor, so knowing if we are at least as good as alpha4 now would be nice.

comment:26 by addos, 5 months ago

Is there a build of this on the nightly builds downloads page I can download? I didn't seem to see it on there?

comment:28 by addos, 5 months ago

Hi, I just tested this build on one of the machines I was having problems with, and it does indeed seem to be performing much better. I won't know for certain until I test the other source machine on Monday. But I think this might have made a big difference.

comment:29 by waddlesplash, 5 months ago

I'm confused as to what you are saying. The nightlies are now almost back to alpha4 performance? Or are the even better than alpha4? Or is alpha4 still better?

comment:30 by addos, 5 months ago

So I have two systems: System 1: the original system, I don't have access to at the moment System 2: the one I have access to at home

When I tried the nightlies on system 1, it was very laggy. Unfortunately, I don't have access to that system until monday.

When I tried alpha 4 on system 2, it seems to be pretty responsive, no lag. I could try to download a recent nightly and try it on system 2, and see if it is laggy again.

comment:31 by addos, 5 months ago

I am noticing on system 2 with the latest nightly. That activity monitor seems to lag, and refresh periodically, but after long periods of time. I notice, though, that if I have the gl tea pot running, it refreshes faster. What could be causing that? I didn't seem to notice any issues clicking items in the tracker/deskbar with this build.

comment:32 by addos, 5 months ago

I made the following video of the laggy performance from the latest nightly on system 2.

https://drive.google.com/open?id=19Cm-huWq1Iu76GUSFNiJkEjecnGWO-J3

comment:33 by diver, 5 months ago

Out of curiosity, can you reproduce it in safe mode?

comment:34 by addos, 5 months ago

I rebooted into safe mode, and yes it is still happening.

comment:35 by addos, 5 months ago

I tried changing various cpu settings in the bios, but none of them had a positive effect. About the only thing that keeps haiku from lagging seems to be booting it with SMP disabled. But performance is subpar when using only a single core. Are there any other suggestions?

comment:36 by addos, 5 months ago

So I have noticed that if I boot with SMP disabled, I see less lag in general, but if I play audio or video, things are still choppy. The only way I got haiku to actually play audio without interruptions is to disable local apic. What exactly is this option doing differently than disabling SMP? Is there anyway to disable the local apic while still having SMP enabled to see if the OS behaves differently? Is there anything that can be determined about what is going wrong with the options I am disabling and the behavior I am seeing in Haiku?

by addos, 5 months ago

Attachment: syslog-20190527.xz added

comment:37 by addos, 5 months ago

I uploaded the syslog from system 2 to the ticket. I tested a workaround suggested by Waddlesplash of blacklisting the cpuidle module. This seems to have done the trick on both systems. They both run significantly faster with no lag. I appreciate all the efforts to hunt and track down what the issue seems to have been. My system runs MUCH faster now!

by addos, 5 months ago

Attachment: syslog-20190528.xz added

syslog from system1

comment:38 by addos, 5 months ago

Added the syslog from system 1.

comment:39 by waddlesplash, 5 months ago

In the future, please don't compress syslogs.

comment:40 by waddlesplash, 5 months ago

I can't find any errata for the Xeon W3520 anywhere about it having broken MWAIT or the like, so I'm not entirely sure why that's the fix.

comment:41 by addos, 5 months ago

I can't explain it either, I just know that the systems are far less laggy when I blacklist cpuidle.

Note: See TracTickets for help on using tickets.