ARM SoC launched with Linux support (Linux Devices) [LWN.net]

ARM SoC launched with Linux support (Linux Devices)

Posted Jan 9, 2009 10:24 UTC (Fri) by ncm (subscriber, #165)
In reply to: ARM SoC launched with Linux support (Linux Devices) by simlo
Parent article: ARM SoC launched with Linux support (Linux Devices)

It seems simpler, safer, and faster for the scheduler to look at the instruction at the return address on the stack of the process being pre-empted, and if it's in the middle of what ought to be an atomic sequence (e.g. a naïve implementation of compare-and-swap) just complete it and update the stacked status word and return address.

(Log in to post comments)

ARM SoC launched with Linux support (Linux Devices)

Posted Jan 9, 2009 12:37 UTC (Fri) by simlo (subscriber, #10866) [Link]

"It seems simpler, safer, and faster"

I can't see any of the 3 to be right:
simpler: How do you determine if this is the case?
safer: What if you where wrong and missed one? What if you where wrong
and some attacher could abuse getting something run in kernel mode?
faster: How can it be faster to make a complicated search into the binary
code than checking the content of one address?

ARM SoC launched with Linux support (Linux Devices)

Posted Jan 9, 2009 20:22 UTC (Fri) by ncm (subscriber, #165) [Link]

Time spent in the kernel scheduler doesn't count, because it happens so rarely. What counts is time spent in user code that isn't pre-empted; incrementing and decrementing a memory word (never mind fooling with a timer!) are expensive. By contrast, code in the kernel to compare a couple of memory words against a pattern is simple, and updating the process state if they match is also simple. So, you just need an instruction sequence that does the right thing very cheaply when it doesn't get pre-empted, and is easy to recognize and patch when it does.

ARM SoC launched with Linux support (Linux Devices)

Posted Jan 9, 2009 22:21 UTC (Fri) by jgg (guest, #55211) [Link]

It is actually a pretty good idea if you combine it with kernel controlled code in the VDSO. Clearly operating on arbitrary user code is not a good idea..

Basically, the kernel has useful atomic_* function calls exported in its VDSO, if ever there is a preemption then during the context switch back to the suspended task the kernel checks if the PC is within the bad portion of the VDSO (two compares) and if so then it inspects the situation in more detail and adjusts the PC to return to the start of the atomic op function and tries again.

Similar precautions can be taken for signals and other cases. The basic structure of the atomic functions in the VDSO would be of the load locked/store conditional type with the kernel providing a loop back to start if the 'reservation' is lost.

User space simply links to these calls like normal VDSO linking. The VDSO is readonly to user space and has a unique physical and virtual address.

If generalized properly it could be efficiency neutral for userspace by being optimized to a specific CPU model. Certainly on ARM it has got to be a win if you need to support all CPU types. PPC and others with ll/sc it might be neutral, if the vdso functions are thick enough to replace what would have been a function call anyhow. Probably not useful on x86..