kernel_thread() causes segfault

[Valdis.Kletnieks at vt.edu]

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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/bc9d8e73/attachment.bin