3 ms·

Random Linux trivia/story: Back in 2002, I was trying to measure the impact of various long-held spinlocks in the kernel. By random chance, I noticed there wa

by elihu 10y ago

Random Linux trivia/story: Back in 2002, I was trying to measure the impact of various long-held spinlocks in the kernel. By random chance, I noticed there was a huge latency spike when I enabled caps-lock. It turns out that it takes about 7 milliseconds to turn a PS/2 keyboard's caps lock LED on (or any of the other LEDs), and the kernel stops what it's doing and waits for it to complete regardless of whatever else it could be doing. There's a command-line tool to turn the LEDs on or off (I forget what it's called), so I integrated that into a test script we used that measures timer latency with various background loads. (We had our own high-resolution timer implementation based on the APIC.) http://jsnow.bootlegether.net/rtas2002.pdf http://jsnow.bootlegether.net/rtas2002.pdf

pjc50 10y ago
I wonder what the latency effect of changing the lights over USB is? Whether it's done at the next polling interval or forces a HID "output report". (The command-line tool you mention is probably xkbleds) For some reason this discussion reminds me of the way the ZX spectrum handled tape input by using a single bit of a register that was shared with the three bits of screen border colour. Because the default tape loader accumulated bits there by shifting the register along at timed intervals, the data loaded produced patterns in the screen border. It didn't have any keyboard LEDs, but the Spectrum did have at least five different input "shift" states - the keyboard was modal and auto-tokenizing.
- elihu 10y ago
  I assume that the usb keyboard driver is completely different code and is unlikely to have the same problem. (One would expect the generic usb implementation to be more carefully designed, since there are so many kinds of usb devices, each with their own unique ways of causing or being adversely affected by scheduling latency.) I haven't done the test, though. In general, this sort of problem is less of an issue now since the transition to multi-core processors means that a long-held spinlock doesn't actually block all progress on the machine. There are usually plenty of other available cores and it's unlikely that unrelated processes are all stuck at the same time.

by elihu 10y ago

pjc50 10y ago

I wonder what the latency effect of changing the lights over USB is? Whether it's done at the next polling interval or forces a HID "output report". (The command-line tool you mention is probably xkbleds) For some reason this discussion reminds me of the way the ZX spectrum handled tape input by using a single bit of a register that was shared with the three bits of screen border colour. Because the default tape loader accumulated bits there by shifting the register along at timed intervals, the data loaded produced patterns in the screen border. It didn't have any keyboard LEDs, but the Spectrum did have at least five different input "shift" states - the keyboard was modal and auto-tokenizing.

elihu 10y ago
I assume that the usb keyboard driver is completely different code and is unlikely to have the same problem. (One would expect the generic usb implementation to be more carefully designed, since there are so many kinds of usb devices, each with their own unique ways of causing or being adversely affected by scheduling latency.) I haven't done the test, though. In general, this sort of problem is less of an issue now since the transition to multi-core processors means that a long-held spinlock doesn't actually block all progress on the machine. There are usually plenty of other available cores and it's unlikely that unrelated processes are all stuck at the same time.