Re: atomic RAM ?

[Michael Schnell]

On 04/12/2010 05:02 PM, Arnd Bergmann wrote:
>
> if you cannot implement a 'test-and-set', 'exchange' or
> 'store-conditional' instruction, I don't think any custom instructions
> will help you.
>   
That is not the point. Custom instructions easily can implement
thread-safe and SMP safe atomic read-modify-write user-land-enabled
operations such as "test-and-set", "exchange" or "inc" (I don't think
that "store conditional" would be necessary). But they can't work if the
same data can be accessed by other (non-custom) CPU instructions, as the
custom-instructions would necessarily bypass the cache and the MMU while
the normal CPU instructions would use both (and as all this is done with
performance in mind disabling or invalidating the cache is out of
question and in user-land such operations are impossible, anyway. This
is why the idea of a dedicated "atomic RAM" has been developed (which
requires the arch-independent Kernel and Library code to access all
would-be "atomic" locations _only_ through arch-depending macros
<including allocating and freeing these memory locations>, even though
for "standard" archs, the resulting ASM code would (hopefully, nearly
everywhere) stay the same as it is).
> You can probably implement an atomic function in a VDSO though, without
> any CPU extensions, I think this has been discussed for blackfin
> before. The idea is to let the kernel check if the instruction pointer
> is in the critical section of the VDSO while returning to user space.
> If it is, the kernel can jump back to the caller of that function
> instead of the function itself, and indicate failure so the user can
> retry.
>   
Right., I already mentioned this "Atomic Region" way to implement an
"atomic operation" workaround for non-SMP systems in the first message
of this thread.

Of course it would be advantageous to have this method for NIOS, as
well, as it can be implemented without "hardware" support and without
modifications of the arch-independent Kernel and library code. But it
will not work with SMP and it will introduces an (even if supposedly not
huge) overhead with any interrupt.

A hardware implementation would avoid this overhead, would allow for
atomic SMP user-land operations and could be the base of implementing an
SMP Kernel (even though with NIOS/SMP other issues <like
cache-synchronization> might need to be solved additionally).

-Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/