[lkml]   [2010]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: atomic RAM ?
    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).


     \ /
      Last update: 2010-04-13 12:15    [W:0.043 / U:2.400 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site