![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Like cures like
Jan. 24th, 2012 08:18 pmJust encountered a curious h/w and s/w related bug.
I was trying to reproduce an issue reported by a customer. The issue was that under certain conditions on some platform some PCI express interrupts were delayed for about 20 usec.
I do not have exactly the same platform, so set up a system with same CPU and similar chipset, then started tweaking. On idle system about 1% of interrupts were delayed by 10 usec. If I reproduce customer's test, up to 5% of interrupts get delayed, but still up to 10 usecs only.
So I was thinking: what else can I do to a system to make performance worse. One obvious idea to check was to assign one of idle cores to run a spin lock, as constant execution of LOCK prefix would be [negatively] affecting all other cores performance. When I did just that, interrupt delays disappeared completely! (Of course average interrupt latency have grown slightly, but is still tolerable)
Will have to investigate further, but looks like now I have an easy solution for a lot of real time related issues: We have a lot of cores, let one of them spin :)
P.S. Of course power management is not an issue, I switch all possible power management features off for this kind of tests.
I was trying to reproduce an issue reported by a customer. The issue was that under certain conditions on some platform some PCI express interrupts were delayed for about 20 usec.
I do not have exactly the same platform, so set up a system with same CPU and similar chipset, then started tweaking. On idle system about 1% of interrupts were delayed by 10 usec. If I reproduce customer's test, up to 5% of interrupts get delayed, but still up to 10 usecs only.
So I was thinking: what else can I do to a system to make performance worse. One obvious idea to check was to assign one of idle cores to run a spin lock, as constant execution of LOCK prefix would be [negatively] affecting all other cores performance. When I did just that, interrupt delays disappeared completely! (Of course average interrupt latency have grown slightly, but is still tolerable)
Will have to investigate further, but looks like now I have an easy solution for a lot of real time related issues: We have a lot of cores, let one of them spin :)
P.S. Of course power management is not an issue, I switch all possible power management features off for this kind of tests.
