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