#10454: New scheduler: substantial performance drop -----------------------------+---------------------------- Reporter: stippi | Owner: pdziepak Type: task | Status: in-progress Priority: high | Milestone: R1 Component: System/Kernel | Version: R1/Development Resolution: | Keywords: Blocked By: 10487 | Blocking: Has a Patch: 0 | Platform: All -----------------------------+---------------------------- Comment (by stippi): It is hard to tell whether the short freezes are related. I have definitely seen freezes in mouse events (1 - 3 secs) on this machine from time to time (before the scheduler merge). These are USB related, the syslog has entries similar to "USB port reset". It gets really bad when I connect my Wacom Intuos 2 tablet. This is definitely unrelated. The short delays while typing only happen very infrequently and I can say that I got aware of them after the scheduler merge, but they might have been there before and might be related to the mouse freezes. I can keep a tail -F syslog open the next time I do some Haiku work. That should clear up at least this issue. My musings about the mysterious latency might not make much sense. I told you that when I run the WonderBrush prototype which uses as much render threads as there are CPU cores, I see those cores all pegged. They wouldn't be if threads are not always allowed to run when they can. To think about the problem as something thread migration related still has some question marks for me. A new task should be scheduled immediately, even when it is short lived. It is either scheduled on a CPU with less load, or on a CPU which is already full, in which case it runs later than it could. If this theory is based on facts, then there should always be at least one CPU under full load. You are saying this may still be the case, only that Activity Monitor misleads by measuring load over such a long interval? -- Ticket URL: <https://dev.haiku-os.org/ticket/10454#comment:11> Haiku <https://dev.haiku-os.org> Haiku - the operating system.