Opened 22 months ago

Last modified 3 weeks 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 22 months ago.
IMAG0534.jpg (4.0 MB) - added by addos 13 months ago.
IMAG0535.jpg (3.9 MB) - added by addos 13 months ago.
IMAG0536-2.jpg (1.7 MB) - added by addos 13 months ago.
syslog-20190527.xz (24.1 KB) - added by addos 3 weeks ago.
syslog-20190528.xz (17.0 KB) - added by addos 3 weeks ago.
syslog from system1

Change History (47)

Changed 22 months ago by addos

Attachment: syslog added

comment:1 Changed 22 months ago by addos

Has a Patch: set

comment:2 Changed 22 months ago by pulkomandy

Has a Patch: unset

comment:3 Changed 18 months ago by addos

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 Changed 13 months ago by addos

Does anyone have any ideas on how to troubleshoot this?

comment:5 Changed 13 months ago by diver

Drop into KDL via kernel_debugger command and run ints.

Changed 13 months ago by addos

Attachment: IMAG0534.jpg added

comment:6 Changed 13 months ago by addos

Attached a new screenshot of ints output from kernel_debugger

comment:7 Changed 13 months ago by korli

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

comment:8 Changed 13 months ago by addos

Here is a screenshot from 51976

Changed 13 months ago by addos

Attachment: IMAG0535.jpg added

comment:9 Changed 13 months ago by korli

The performance is the same?

comment:10 Changed 13 months ago by addos

Yes, very very choppy.

comment:11 Changed 13 months ago by addos

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

comment:12 Changed 13 months ago by korli

you could try to disable the ipro1000 driver.

comment:13 Changed 13 months ago by addos

How should I disable the driver?

comment:15 Changed 13 months ago by addos

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.

Changed 13 months ago by addos

Attachment: IMAG0536-2.jpg added

comment:16 Changed 13 months ago by korli

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 Changed 13 months ago by diver

Does disabling SMP in the bootloader fixes choppiness?

comment:18 Changed 13 months ago by addos

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

comment:19 Changed 7 months ago by waddlesplash

How is this with beta1?

comment:20 Changed 7 months ago by addos

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 Changed 5 weeks ago by waddlesplash

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

comment:22 Changed 5 weeks ago by waddlesplash

Component: - GeneralSystem

comment:23 Changed 4 weeks ago by addos

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 Changed 4 weeks ago by addos

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 Changed 4 weeks ago by waddlesplash

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 Changed 4 weeks ago by addos

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 Changed 4 weeks ago by addos

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 Changed 4 weeks ago by waddlesplash

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 Changed 4 weeks ago by addos

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 Changed 4 weeks ago by addos

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 Changed 4 weeks ago by addos

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 Changed 4 weeks ago by diver

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

comment:34 Changed 4 weeks ago by addos

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

comment:35 Changed 4 weeks ago by addos

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 Changed 3 weeks ago by addos

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?

Changed 3 weeks ago by addos

Attachment: syslog-20190527.xz added

comment:37 Changed 3 weeks ago by addos

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!

Changed 3 weeks ago by addos

Attachment: syslog-20190528.xz added

syslog from system1

comment:38 Changed 3 weeks ago by addos

Added the syslog from system 1.

comment:39 Changed 3 weeks ago by waddlesplash

In the future, please don't compress syslogs.

comment:40 Changed 3 weeks ago by waddlesplash

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 Changed 3 weeks ago by addos

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.