preemptive kernels and the use of smp_processor_id()

[Valdis.Kletnieks at vt.edu]

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