3 ms·

> 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

> 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?

jeffbee 6y ago
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?
- jstimpfle 6y ago
  Not a kernel person, but how about a flag for the thread data structure?
  - jeffbee 6y ago
    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.
xymostech 6y ago
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.
jabl 6y ago
I vaguely recall that the Linux kernel has used lazy save/restore of FP registers since way back when.
PaulDavisThe1st 6y ago
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.

jeffbee 6y ago

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?

jstimpfle 6y ago
Not a kernel person, but how about a flag for the thread data structure?
- jeffbee 6y ago
  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.

xymostech 6y ago

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.

jabl 6y ago

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

PaulDavisThe1st 6y ago

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.