Hacker News Reader

Comment by jstimpfle | Hacker News Reader

> Why can’t the kernel implementation use AVX? Well, if it did, then it would have to save and restore those registers on each system call, and that would make domain crossing even more expensive. So this was a conscious decision in the Linux kernel.

I don't follow. So a syscall that could profit from AVX can't use it because then all syscalls would have to restore AVX registers? Why can't the restoring just happen specifically in those syscalls that make use of AVX?

View on HN

It's not just syscalls. It's every context switch. If the process is in the midst of using AVX registers in kernel code, but is suddenly descheduled, those registers have to be saved/restored. You can't know if the task is using AVX or not, so you have to either always save/restore them, or adopt the policy that these registers are not saved/restored.

I vaguely recall that the Linux kernel has used lazy save/restore of FP registers since way back when.

I think by "each system call" she meant it like "every time it calls read()", since it would be read() that was using the AVX registers. Since the example program just calls read() over and over, this could add a significant amount of overhead.

You'd have to have a static analysis of which syscalls can transitively reach which functions, which is probably not possible because linux uses tables of function pointers for many purposes. Also if thread 1 enters the kernel, suspends waiting for some i/o, and the kernel switches to thread 2, how would it know it needed to restore thread 2's registers because of AVX activity of thread 1? And if it did how would it have known to save them?

Not a kernel person, but how about a flag for the thread data structure?

Yeah actually now that I'm part way through that first cup of coffee, the 2nd part of my comment doesn't make sense, the kernel already has to do a heavier save of a task's register state when it switches tasks.

Reply on news.ycombinator.com