From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3F1301F47C for ; Wed, 18 Jan 2023 15:48:42 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=d7E7pA7f; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 438103858C60 for ; Wed, 18 Jan 2023 15:48:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 438103858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674056921; bh=YKpXZwRdznqrSn3B5VyDwfgCrn0W1uHqf0zlXeN5X2Q=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=d7E7pA7fDPbsCCEfnhhhXfYGciprVLob0wA400djWJO0MXMYhBDZtJoFKN8xaVwq/ w9JE3UD95ZB+k1Idwi4ji431Zg6mmnWuZ8Vf62rWdh5A5Q6QZE5sJ40FJMCtY7jtA6 d1s4ztfBL3Me6dzZ84eajaQLTksKd1EziPrRCZ2c= Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by sourceware.org (Postfix) with ESMTPS id E02CF3858C30 for ; Wed, 18 Jan 2023 15:48:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E02CF3858C30 Received: from [172.16.0.101] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4Nxqsm45hZzh9S; Wed, 18 Jan 2023 10:48:12 -0500 (EST) Message-ID: Date: Wed, 18 Jan 2023 10:48:46 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [RFC/PoC] malloc: use wfcqueue to speed up remote frees Content-Language: en-US To: Eric Wong , Carlos O'Donell Cc: libc-alpha@sourceware.org References: <20180731084936.g4yw6wnvt677miti@dcvr> <0cfdccea-d173-486c-85f4-27e285a30a1a@redhat.com> <20180731231819.57xsqvdfdyfxrzy5@whir> <20230117064251.M336757@dcvr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mathieu Desnoyers via Libc-alpha Reply-To: Mathieu Desnoyers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 2023-01-17 14:05, Mathieu Desnoyers wrote: > On 2023-01-17 01:42, Eric Wong wrote: >> Carlos O'Donell wrote: >>>>> - Adding urcu as a build-time dependency is not acceptable for >>>>> bootstrap, instead we would bundle a copy of urcu and keep it >>>>> in sync with upstream. Would that make your work easier? >>> >>> Eric Wong wrote: >>>> Yes, bundling that sounds great.  I assume it's something for >>>> you or one of the regular contributors to work on (build systems >>>> scare me :x) >>> >>> Yes, that is something we'd have to do. >> >> Hi, bringing this topic from 2018 up again (+Cc Mathieu): >> https://inbox.sourceware.org/libc-alpha/c061de55-cc2a-88fe-564b-2ea9c4a7e632@redhat.com/T/ >> >> I'm wondering if URCU-in-glibc is still on the table.  I'm also >> considering an learning C11 atomics and deriving a standalone >> wfcqueue w/o URCU atomics. > > Hi Eric, > > I'm very much interested to contribute portions of liburcu to glibc. I > think what we would need at this point is to document where we see that > liburcu infrastructure can improve glibc, and create a gradual > integration roadmap based on priorities. We should identify the > stake-holders interested in seeing this done, and then we can discuss > the time-frame and resources available for this project. > > That being said, I suspect we'd want to cover a few pieces of technology > in this list, namely: > > - Restartable Sequences (rseq system call), > - membarrier system call, > - liburcu and libside [1,2] RCU implementations, > - liburcu data structures (e.g. wfcqueue). Here is a PoC implementing liburcu wfcqueue with C11 atomics: https://review.lttng.org/c/userspace-rcu/+/9271 PoC: wfcqueue: remove dependencies on liburcu headers Feedback is welcome! Thanks, Mathieu > > I would be tempted to go for an approach closer to the RCU > implementation I have done in the libside project for glibc, because it > supports having multiple RCU grace period domains per process, which > allows to nicely split the locking dependencies into sub-domains, and > therefore lessen the chances of deadlocks due to nesting of a > global-domain RCU read-side/synchronize_rcu, and locking (e.g. mutexes). > > Thanks, > > Mathieu > > [1] https://github.com/efficios/libside/blob/master/src/rcu.c > [2] https://github.com/efficios/libside/blob/master/src/rcu.h > -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com