On Thursday 13 August 2009 03:22:43 Michael Schnell wrote: > Mike Frysinger wrote: > > - next ~1k is user-space atomic code (initialized by kernel at boot) > > > > so when userspace wants to do atomic functions (since the hardware doesnt > > support it), it calls the functions hardcoded in this region. when the > > kernel goes to return to userspace, it checks the PC isnt in this region. > > if it is, it will finish the atomic operation for userspace and update > > the PC. > > How exactly is this done ? > > I suppose it imposes some additional overhead to each interrupt, as on > entry or exit there is some code that checks whether the PC had been in > that region (this is what you say).
the overhead is trivial and occurs just before resuming userspace. if the
userspace PC is inside of the fixed atomic section range, then we finish the
function execution in kernel space and update the PC.
so in the most common case (userspace is not in the atomic section), the
overhead is two compares (and related branching). in the uncommon case, the
overhead is unavoidable. in much older versions of the Blackfin port, we had
created a dedicated cmpxchg syscall for userspace to use, but we found the
performance of that was incredibly worse compared to what we have now.
arch/blackfin/...
.../mach-common/entry.S
- schedule_and_signal_from_int calls finish_atomic_sections
.../kernel/process.c
- finish_atomic_sections takes care of register munging
.../kernel/fixed_code.S
- this is the pure assembly that is relocated at kernel boot time
> If it is I suppose some "interesting" code is necessary to find out if
> the should-be atomic code sequence already is finished (with a write
> memory instruction) or if it is not yet finished and according to that
> act appropriately by - only in case of not finished - setting the return
> PC to the point of restarting the atomic code sequence.
>
> Moreover each atomic_xxx() function needs some additional overhead as it
> can't be inlined but needs a far call (and thus additional cache usage)
> to the special region.
>
> Are some atomic functions predefined in the said region or do the user
> space programs need to create them (in fact I suppose the region is
> write protected, if that is possible with the chip ??? ) ?
>
> Do you thinks this is an appropriate addition to the NIOS2 distribution
> ? (My other idea is to do a hardware "custom instruction" that creates a
> dedicated Futex that can be used to protect atomic code sequences.)
i'm not entirely sure what you're talking about here. the fixed code we have
is for user space only and is not used directly by kernel space at all. the
atomic functions are all trivial and impotent, so doing the register/memory
munging directly and setting the PC to the end of the relevant function is
easy to do.
-mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
