Re:kernel_thread() causes segfault
What is the usecase here ? Do we need to share the entire process address space to a kernel thread ? If address space sharing between userspace thread and kernel thread space is the whole idea then we can mmap process address space and do get_user_pages() to allocate physcial page and pin it. kernel thread can do kmap() and kumap() to use the pages from process address space. http://lxr.free-electrons.com/source/fs/aio.c?v=3.8#L99 Regards Manoj Nayak
I am trying to implement ideas mentioned in the following OSDI paper: L. Soares and M. Stumm. FlexSC: flexible system call scheduling with exception-less system calls. In Proc. OSDI, 2010. http://www.cs.cmu.edu/~chensm/Big_Data_reading_group/papers/flexsc-osdi10.pd... The paper propose a new mechanism for applications to make syscall. The brief idea is to have two types of threads 1) User thread 2) Kernel Thread. 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*.* So to implement this mechanism, it is important for the user and kernel thread to share address space, fd tables etc. kernel_thread() works fine with older kernels to achieve this task, but is no longer an option. Is there of any mechanism for sharing fd tables as well? Please let me know. Thanks a lot, Shashank
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....
participants (3)
-
Manoj Nayak -
Shashank Khasare -
Valdis.Kletnieks＠vt.edu