From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout.efficios.com (unknown [IPv6:2607:5300:203:b2ee::31e5]) by sourceware.org (Postfix) with ESMTPS id 25B5F3858C60 for ; Wed, 18 Jan 2023 14:52:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 25B5F3858C60 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1674053571; bh=dyxwC0qhIDpr8iOYQ+jfa48FkFcQA0NmnIHZppXL6hI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=A1JZQJUVuxQUo13deCj1Y5FSxPIe4jjpb4e1zXUkPLaNPzKyFM+Cu/H0qD24GrfvJ xXYJGHv1qFngPv+YTmqKXqy2CxSi+E3JuO1sJJ9hQzsGWl6XTyixj091ctLhgxBIi/ n5V4XuSHjg7430dthrznCu723TYmDY/2sxHm5fa1oNCb44YWCX6Qjc4rv5dC07Wxmy MKq0xNpgFB6soQg23phCtuqp4CNI6RAb7fQf3aK21DGzGX/3nSxId9hB2vSfzr6He9 Jolo8evuky+TZ2osG8iFkjB1mDj93e279jgo4MIQ6TJvpFVIO94V1iFPGgu5Eef028 +uBONTm6n0CLg== 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 4Nxpdt6bdSzgns; Wed, 18 Jan 2023 09:52:50 -0500 (EST) Message-ID: <084051cc-7ddb-eb66-3361-41a7eb79d959@efficios.com> Date: Wed, 18 Jan 2023 09:53:24 -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> From: Mathieu Desnoyers In-Reply-To: <20230117064251.M336757@dcvr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. I've done a quick review of your proposed patch, and there is one thing that I'm concerned about: forward progress of remote_free_finish(). AFAIU, if we have a steady flow of remote_free_begin() calls, it can prevent forward progress of the anena owner. When remote_free_step() captures the queue (splice) and processes it, it returns whether it has processed any elements, and the caller attempts to splice again if there was anything present. What I wonder is why is it required that the caller splices queue elements that were queued _after_ the begin of remote_free_finish() ? Can't we simply leave those to the next (eventual) remote_free_finish calls ? If we do that change, this means remote_free_finish would only be needed when tearing down an arena, and upon allocation only a single call to remote_free_step() would be needed. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com