On Tue, 22 Mar 2016 16:51:44 +0530, Shashank Khasare said: > These two threads share same address space, file descriptor tables, parent > pid etc. > Whenever user thread wants to make syscall, it would post the information > about syscall number & arguments > to syscall in common shared page. User thread would then wait till the > results are posted on shared page. > The kernel thread reads the syscall arguments from shared page and writes > the results to shared page. > User thread consumes the results and continues execution. > Since the kernel thread and user thread can be scheduled on different cpu > cores, and user thread is ideally never executing > kernel code and vice versa, one can expect gain in instruction per cycle > for application, since the cache pollution is reduced to > some extent*.* However, you're almost certainly going to lose those gained cycles in the latency waiting for the kernel side to notice a newly posted syscall (what are you going to do, poll? How well does that work if you have several hundred or thousands of processes running?) - and then you have to have userspace wake up properly (hint - *it* can't spin and poll, because if it's running, kernelspace can't be running to service its request). Also, if the kernel and user threads are on different cores, you have the potential of cache line ping-ponging.... There's a *reason* why a lot of academic papers don't make it into production code....
Attachment:
pgpEC59jZHqSZ.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
