...
Q1: Should Arachne know about the blocked user thread?
hq6: There does not seem to be much use in Arachne being aware of the blocked user thread, since it is blocked due to a kernel operation, and there's not much Arachne could do with that information.
Q2: How do we notice the blocking syscall finishes if we have disabled the interrupts to achieve full core isolation?
hq6: It may make sense to keep device interrupts, and disable only timer interrupts.
Q3: Should we consider the possibility of async. syscall mechanism (e.g., FlexSC, Linux Syslets, etc.)?
hq6: Time permitting, we should experiment with the FlexSC idea of piling up syscalls on a remote core and measure application-level throughput and latency under load. The hidden costs of context switching between the user and kernel that FlexSC aims to reduce still exists in our scheme above.
Q4: What if we have too many threads blocking in the syscalls at the same time? Should we try to cap the size of the thread pool?
hq6: This seems like a self-limiting problem, in the sense that if the core is spending a large proportion of time in the kernel and handling interrupts due to IO completions, then it will not have much time to accept many new user threads to issue further syscalls.
Q5: Is the scheduling class going to be notified when threads are blocked on syscalls and woken?
...