> I'm curious whether it is correct to just set the prev->refs to zero and
> return
> @prev? So that it can remove an unneeded "add()&get()" pair (although in
> an unlikely branch) and __freelist_add() can be folded into freelist_add()
> for tidier code.
That is a very good question. I believe it
On Fri, Aug 28, 2020 at 04:46:52PM +0200, Oleg Nesterov wrote:
> On 08/27, Peter Zijlstra wrote:
> >
> > 1 file changed, 129 insertions(+)
>
> 129 lines! And I spent more than 2 hours trying to understand these
> 129 lines ;) looks correct...
Yes, even though it already has a bunch of comments,
On 08/27, Peter Zijlstra wrote:
>
> 1 file changed, 129 insertions(+)
129 lines! And I spent more than 2 hours trying to understand these
129 lines ;) looks correct...
However, I still can't understand the usage of _acquire/release ops
in this code.
> +static inline void __freelist_add(struct f
On Fri, Aug 28, 2020 at 12:23 AM Peter Zijlstra wrote:
> +static inline void __freelist_add(struct freelist_node *node, struct
> freelist_head *list)
> +{
> + /*
> +* Since the refcount is zero, and nobody can increase it once it's
> +* zero (except us, and we run only one
On Thu, Aug 27, 2020 at 03:57:22PM -0400, Cameron wrote:
> On Thu, Aug 27, 2020 at 3:08 PM Boqun Feng wrote:
> > So if try_cmpxchg_acquire() fails, we don't have ACQUIRE semantics on
> > read of the new list->head, right? Then probably a
> > smp_mb__after_atomic() is needed in that case?
>
> Yes,
On Thu, Aug 27, 2020 at 3:08 PM Boqun Feng wrote:
> So if try_cmpxchg_acquire() fails, we don't have ACQUIRE semantics on
> read of the new list->head, right? Then probably a
> smp_mb__after_atomic() is needed in that case?
Yes, there needs to be an acquire on the head after a failed cmpxchg;
doe
On Thu, Aug 27, 2020 at 06:12:43PM +0200, Peter Zijlstra wrote:
>
>
> Cc: came...@moodycamel.com
> Cc: o...@redhat.com
> Cc: w...@kernel.org
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> include/linux/freelist.h | 129
> +++
> 1 file changed, 129
On Thu, Aug 27, 2020 at 12:56 PM wrote:
> Are you Ok with the License I put on it, GPLv2 or BDS-2 ?
Yes, both GPLv2 and BSD-2 (my personal favourite) are fine.
On Thu, Aug 27, 2020 at 12:49:20PM -0400, Cameron wrote:
> For what it's worth, the freelist.h code seems to be a faithful adaptation
> of my original blog post code. Didn't think it would end up in the Linux
> kernel one day :-)
Hehe, I ran into the traditional ABA problem for the lockless stack
On Thu, Aug 27, 2020 at 06:12:43PM +0200, Peter Zijlstra wrote:
> +struct freelist_node {
> + atomic_trefs;
> + struct freelist_node*next;
> +};
Bah, the next patch relies on this structure to be ordered the other
way around.
Clearly writing code and listening to talks
10 matches
Mail list logo
