search for: atomic_test_and_set

Displaying 9 results from an estimated 9 matches for "atomic_test_and_set".

2014 Apr 18
1
[PATCH v9 06/19] qspinlock: prolong the stay in the pending bit path
On Thu, Apr 17, 2014 at 09:46:04PM -0400, Waiman Long wrote: > BTW, I didn't test out your atomic_test_and_set() change. Did it provide a > noticeable performance benefit when compared with cmpxchg()? I've not tested that I think. I had a hard time showing that cmpxchg loops were slower, but once I did, I simply replaced all cmpxchg loops with unconditional ops where possible. The machine that was...
2014 Apr 18
1
[PATCH v9 06/19] qspinlock: prolong the stay in the pending bit path
On Thu, Apr 17, 2014 at 09:46:04PM -0400, Waiman Long wrote: > BTW, I didn't test out your atomic_test_and_set() change. Did it provide a > noticeable performance benefit when compared with cmpxchg()? I've not tested that I think. I had a hard time showing that cmpxchg loops were slower, but once I did, I simply replaced all cmpxchg loops with unconditional ops where possible. The machine that was...
2014 Apr 17
2
[PATCH v9 06/19] qspinlock: prolong the stay in the pending bit path
On Thu, Apr 17, 2014 at 11:03:58AM -0400, Waiman Long wrote: > There is a problem in the current trylock_pending() function. When the > lock is free, but the pending bit holder hasn't grabbed the lock & > cleared the pending bit yet, the trylock_pending() function will fail. I remember seeing some of this.. > It can be seen that the queue spinlock is slower than the ticket
2014 Apr 17
2
[PATCH v9 06/19] qspinlock: prolong the stay in the pending bit path
On Thu, Apr 17, 2014 at 11:03:58AM -0400, Waiman Long wrote: > There is a problem in the current trylock_pending() function. When the > lock is free, but the pending bit holder hasn't grabbed the lock & > cleared the pending bit yet, the trylock_pending() function will fail. I remember seeing some of this.. > It can be seen that the queue spinlock is slower than the ticket
2009 Oct 30
2
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...ch_state = 0;// for each callsite one byte of memory callsite: if (atomic_load(&callsite_patch_state) == 2) { //fast-path: already compiled and patched patchsite: jmp <nop nop nop nop nop nop nop nop> // will be patched } // not yet patched, it may already be compiling if (atomic_test_and_set(&callsite_patch_state, 0, 1) == 0) { // not yet compiling, set state to compiling, and start compiling call CompilationCallBack // set state to patched atomic_set(&callsite_patch_state, 2) } // wait for patched state while (atomic_load(&callsite_patch_state) != 2...
2014 Apr 18
0
[PATCH v9 06/19] qspinlock: prolong the stay in the pending bit path
...our (endian challenged) clear_pending_set_locked(). The code is just to extend the timing window a bit more to include cases where the lock holder is about to release the lock. It applies to both cases. However, it is not strictly necessary and I can take it out. BTW, I didn't test out your atomic_test_and_set() change. Did it provide a noticeable performance benefit when compared with cmpxchg()? >> + } else if ((val& _Q_LOCKED_PENDING_MASK) == _Q_PENDING_VAL) { >> + /* >> + * Pending bit is set, but not the lock bit. >> + * Assuming that the pending bit holder is...
2009 Nov 01
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...of memory > > callsite: > if  (atomic_load(&callsite_patch_state) == 2) { >      //fast-path: already compiled and patched > patchsite: >       jmp <nop nop nop nop nop nop nop nop> // will be patched > } > // not yet patched, it may already be compiling > if  (atomic_test_and_set(&callsite_patch_state, 0, 1) == 0) { >      // not yet compiling, set state to compiling, and start compiling >      call CompilationCallBack >      // set state to patched >      atomic_set(&callsite_patch_state, 2) > } > // wait for patched state > while (atomic_load(...
2009 Oct 29
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Hi Jeffrey, > > Jeffrey Yasskin wrote: >> >> Cool, I'll start implementing it. >> > > Great! Thanks. > > Just to clarify things: on my end, it doesn't really matter what is the > default behavior, as long as vmkit can continue to have the existing >
2009 Oct 29
3
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
Hi Jeffrey, Jeffrey Yasskin wrote: > Cool, I'll start implementing it. > Great! Thanks. Just to clarify things: on my end, it doesn't really matter what is the default behavior, as long as vmkit can continue to have the existing behavior of lazy compilation. With Chris' solution, I was wondering how you would implement the getPointerToFunction{Eager, Lazy} functions when