ARMv7 suggests that you are supposed to put spinlocks and semaphores in uncached regions. However, this breaks much uniformity of the kernel and makes the memory management of kernel objects more complicated. When synchronization primitives are outside the actual object, allocated separately adds an extra level of indirection and memory fragmentation as well as TLB misses. A majority of the objects must have some kind of synchronization primitive so why couldn't they solve this by having these primitives in the same memory area (cached, sharable) as the general kernel data.
This applies for ARM but how is it on other architectures like x86 and MIPS for example? Do we have to design the kernel so that the synchronization primitives must always be allocated separately?
Syncronization primitives in uncached areas necessary?
-
- Member
- Posts: 595
- Joined: Mon Jul 05, 2010 4:15 pm
- Owen
- Member
- Posts: 1700
- Joined: Fri Jun 13, 2008 3:21 pm
- Location: Cambridge, United Kingdom
- Contact:
Re: Syncronization primitives in uncached areas necessary?
Citation?
This contravenes all the information on ldrex/strex/clrex I've read in the ARMv7ARM
This contravenes all the information on ldrex/strex/clrex I've read in the ARMv7ARM
-
- Member
- Posts: 595
- Joined: Mon Jul 05, 2010 4:15 pm
Re: Syncronization primitives in uncached areas necessary?
From ARM Architecture Reference Manual by ARM themselves.1. A system with multiple bus masters that uses Swap instructions to implement semaphores that control
interactions between different bus masters.
In this case, the semaphores must be placed in an uncached region of memory, where any buffering
of writes occurs at a point common to all bus masters using the mechanism. The Swap instruction
then causes a locked read-write bus transaction.
Now there is this extra condition with multiple bus master and I don't where this applies.
- Owen
- Member
- Posts: 1700
- Joined: Fri Jun 13, 2008 3:21 pm
- Location: Cambridge, United Kingdom
- Contact:
Re: Syncronization primitives in uncached areas necessary?
The SWP/SWPB instructions are deprecated in ARMv6K, (IIRC) optional in ARMv7 with multiprocessing extensions, probably UNDEFINED in ARMv8, and, as you've observed from the manuals, do not work on cached memory when you have multiple processors.
Use the ARMv6K LDREX/STREX instructions instead.
Use the ARMv6K LDREX/STREX instructions instead.
-
- Member
- Posts: 595
- Joined: Mon Jul 05, 2010 4:15 pm
Re: Syncronization primitives in uncached areas necessary?
Alright, that's good news and ARM has paid attention a little bit making it easier for system programmers.
Back to the general question then, in a kernel design should the synchronization primitives be separate from the kernel object in order accommodate cases like this or are they so uncommon that I don't need to bother with them?
Back to the general question then, in a kernel design should the synchronization primitives be separate from the kernel object in order accommodate cases like this or are they so uncommon that I don't need to bother with them?
- Owen
- Member
- Posts: 1700
- Joined: Fri Jun 13, 2008 3:21 pm
- Location: Cambridge, United Kingdom
- Contact:
Re: Syncronization primitives in uncached areas necessary?
I don't think anyone has been so braindead to make an architecture where the synchronization primitives don't work in cached areas in multi processor configs (SWP was obsoleted before any SMP ARMs came along)