Syncronization primitives in uncached areas necessary?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
OSwhatever
Member
Member
Posts: 595
Joined: Mon Jul 05, 2010 4:15 pm

Syncronization primitives in uncached areas necessary?

Post by OSwhatever »

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?
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:

Re: Syncronization primitives in uncached areas necessary?

Post by Owen »

Citation?

This contravenes all the information on ldrex/strex/clrex I've read in the ARMv7ARM
OSwhatever
Member
Member
Posts: 595
Joined: Mon Jul 05, 2010 4:15 pm

Re: Syncronization primitives in uncached areas necessary?

Post by OSwhatever »

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.
From ARM Architecture Reference Manual by ARM themselves.

Now there is this extra condition with multiple bus master and I don't where this applies.
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:

Re: Syncronization primitives in uncached areas necessary?

Post by Owen »

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.
OSwhatever
Member
Member
Posts: 595
Joined: Mon Jul 05, 2010 4:15 pm

Re: Syncronization primitives in uncached areas necessary?

Post by OSwhatever »

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?
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:

Re: Syncronization primitives in uncached areas necessary?

Post by Owen »

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)
Post Reply