On Tue, 09 Jul 2013 12:20:41 +0200, Christian Parpart said: > So it seems the kernel module I am porting assumed to always run > on the same CPU core once entered kernelspace, but on a preemptive > system you cannot guarantee that. Correct. You probably want to fix the assumption(s) in the kernel module, that's in the long term probably easier than trying to make it work otherwise > So my question is, how > can I force certain calls not to be preempted by the scheduler and/or > not changing the core it was running on? The trick is that if you're not interruptible, you can't be pre-empted. Note however that *does* limit what you can do - for instance, memory allocations that might sleep will cause problems. Also, since any running non-preemptible increases latency for whatever wanted to preempt you, you want to minimize the size of such regions as much as possible. > 2.) there is one part in the kernel where it actually uses the smp_processor_id() > value for further tests, so here it really shouldn't reschedule during the call - The big question is why the code cares. Unless you're running on a non-symmetric configuration where the processor feature set differs, you usually don't care what CPU you're on - but you *may* care about something affected by the CPU (for example, cache line ping-ponging). It may make sense to not worry as much about what processor you're on and instead think of ways to deal with the issue you're trying to solve by selecting the processor (for instance, firing an IPI to run the critical code on the CPU that it needs to be on).
Attachment:
pgpJK4GlYQsrc.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
