On Sun, 2013-02-17 at 18:05 -0800, Greg KH wrote: > On Sun, Feb 17, 2013 at 02:37:24PM +0000, Jonathan Andrews wrote: > > From a user perspective it seems a bit crap to have to change the kernel > > if you have a workload that preemption is harmful to. > > In the case of something like the Raspberry Pi changing the kernel if > > the distribution has not done the work for me sounds like real effort. > > The kernel is tied to binary obscurity from broadcom... To build I need > > a working cross compiler, toolchain, kernel sources, Pi specific patches > > then to get everything in the correct place on an SD card containing two > > filesystems. Its possible but its not going to "just work" at my skill > > level.... > > As you can not boot a kernel.org kernel on the RPI platform just yet, > there's very little that the kernel.org community can do here to help > you out. Somebody could stick in the code to enable/disable preemption at runtime on PREEMPT compiled kernels :-) - Then all I have to do is wait for it to filter down to the Raspian kernel maintainers, i'm patient ;-) ?
In all seriousness I assume preemption has a timer and an interrupt vector, cant the timer simply be enabled/disabled leaving just the kernel call mechanism untouched. IE a "preemption" kernel that is now not preempting ...... OK, OK - I have many other egg sucking suggestions but am I the only one who wants the functionality ? Seems a half step to add all this wizzy real-time code to the kernel then stop users doing real-time in user space by allowing the schedular to yield during what a user wishes to be a citical section (from a timing point of view not the atomic point of view). What about a yield alignment mechanism for user space. IE the process calls the kernel with a request "schedule me first after a yeild" - then the process at least has whatever the timer granularity is to do something timing critical... add a flag to ignore or defer interrupts and you have a semi 'hard-realtime' behaviour for user space, allowing user space to grab small chunks of real time. Yes a nasty looking facility for SMP intel servers but really useful for embedded. > I suggest you go take this up with the developers whom you got > this specific kernel build from, there's nothing we can do here about > it. I suspected it was not going to be simple. As I suspect my feature request is not that simple but if you don't ask........ Thanks, Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/