Hi,
Sorry for late reply.
On Fri, 10 May 2024 10:20:56 +0200
Vlastimil Babka wrote:
> On 5/10/24 9:59 AM, wuqiang.matt wrote:
> > On 2024/5/7 21:55, Vlastimil Babka wrote:
> >>
> >>> + } while (!try_cmpxchg_acquire(>tail, , tail + 1));
> >>> +
> >>> + /* now the tail position is reserved for
On 2024/5/10 16:20, Vlastimil Babka wrote:
On 5/10/24 9:59 AM, wuqiang.matt wrote:
On 2024/5/7 21:55, Vlastimil Babka wrote:
>>
+ } while (!try_cmpxchg_acquire(>tail, , tail + 1));
+
+ /* now the tail position is reserved for the given obj */
+
On 5/10/24 9:59 AM, wuqiang.matt wrote:
> On 2024/5/7 21:55, Vlastimil Babka wrote:
>>
>>> + } while (!try_cmpxchg_acquire(>tail, , tail + 1));
>>> +
>>> + /* now the tail position is reserved for the given obj */
>>> + WRITE_ONCE(slot->entries[tail & slot->mask], obj);
>>> + /* update
On 2024/5/7 21:55, Vlastimil Babka wrote:
On 4/24/24 11:52 PM, Andrii Nakryiko wrote:
objpool_push() and objpool_pop() are very performance-critical functions
and can be called very frequently in kretprobe triggering path.
As such, it makes sense to allow compiler to inline them completely to
On 4/24/24 11:52 PM, Andrii Nakryiko wrote:
> objpool_push() and objpool_pop() are very performance-critical functions
> and can be called very frequently in kretprobe triggering path.
>
> As such, it makes sense to allow compiler to inline them completely to
> eliminate function calls overhead.
objpool_push() and objpool_pop() are very performance-critical functions
and can be called very frequently in kretprobe triggering path.
As such, it makes sense to allow compiler to inline them completely to
eliminate function calls overhead. Luckily, their logic is quite well
isolated and
