From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3615 invoked from network); 31 Jul 2020 17:22:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 31 Jul 2020 17:22:32 -0000 Received: (qmail 11290 invoked by uid 550); 31 Jul 2020 17:22:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11272 invoked from network); 31 Jul 2020 17:22:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1596216136; bh=T4LYDr44ipFttjvEMWarYOKorjDZq/KO+CjaQ/X2D1U=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=ezN8lnLFnkF71hCtDY0wCqBka/dTQ4gU0WHRUveeKDhVvTGCgM4q1apAYCx5C0uz1 hoCLf5k394qLbneQ6eQKkO2QuzgPWR6EF1ya00As3HebeUKpoWwv2F3Q9437LsxnNo T7E29VftBiEBSVaY52NKgp31BWHdlqj/aCeunn+c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Fri, 31 Jul 2020 19:22:16 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200731172216.GB2076@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:7KOzOMaHXwkrhso2KncD2oyGchkD6Ok0j8BuSE3rOzpLMnQD2Jl fPZyGZa8Qu3OqIozO0X6Luh1LuUo0NotY9762me2iPOxJDbwSFMGmAmfsWcnwnViQCGxCR1 Sf71tVP9fggmud9J5xuzMOmjX3n1q6RI4gZxM4s+3tV7RH5VFQL/LCrbUDuQIKthFH8w6je fUMOwPEZ/W+22UwROn9CA== X-UI-Out-Filterresults: notjunk:1;V03:K0:z1U0lRduYmI=:k0klNpFo1qSxQuZCPWmfPg DvKYKnLZqpRSgIN/xDCAqTF2RxTPT6SH93l/9UQNOFNf+aGc+2i+G5irmt7ev0adyc5bdb2// TC69/mvnHRBlzVGMekW8JaiTOtj45CfD9SXlnVfsvwc/a+ApKumRwlINQvZ6YjemidgInQkBU ondyIxksxDWQh/zFwKmekN5+x7Co0J5rt2EYjV6iWOqiLgkLTrWq+9drzf9PJjlcdtbm12YJr NeJJnSIXUBQHVFjw02ci+IH8Iw1CS8ir4/U3t7pq3Vueb77dbpkvYOKFOqXJb2ioc8okxP5+x DzSUgNyWVL2ksgvZkVvMncXynKwpcDxIuyMgCzDbeuHScw7gqHmmMqKJUjQcncy3Q0fLtbp8X Mc1hIL6+qPJkX+3Or5+TELSuNQzVBWd4jJKwGHSNJrabB7QAhRv86891UggRRbN1W6fmyqjPL 15XWsUAcJBpuoc6QORtcQJ0C4ifhHgLPbrUImJb4nlia4LKA9P0zJS2u68X0pyL29Ew7DLUIA tfOJS0oXOvhevOdNI75It+oh8le6BJiebAFOJUJPz5tSHPLyqhELhnpmFcfFgjbXvRz4nxSeR H/CViKtKhLqry+noN0JIWN3REjNZa7YVwb4yqTn6whM4IepM9ww0XTcJVxViCzAt7397BAezH tJch03Qnk2aFLwue5f36ztPBwljDup+ehYssHD0m4BOTCUPqXSWaB1CcANJGHyA5SN7SYa9mc XB5Td/bJ2Zr974LxuyzQQhZIg4Rl5H2cd13y3c7xCixfJnQoItRGkBHvDh/9FI1aRgBXBZ+nW Cort498VueQ0xCiL/n4VeO8yD0ne05pWO8f5D0uf75bqDYTJ49wx2QF4PRR58/RO227rXuwOL yskLbqfUqXrVsC3HBUGqyOks9e+8+apZ0yXr0HE06DnKdXvMe2Iv750VVoYowYw9xFYdNB2vV 39yDRwayA0IW79uMPk8bb6qoTAgyMkJ66ic2KMOwulpY6afqzdejvNuLzKJscFa6WyL+YaOsE m/BWdd3Ghu1NYztFkCL0jbzGgyYDUsmt0DHe24o7BDo2Rzt3lcE3HGXq3uOMt/CRlkZsjfuYg 8M/rrW3N/PDmDU0gRJE5fejhD4LlpG23xRiwsqM5EFVCOTrD86qfWUxvgJ4/jlB7m6q7ABsE3 YLjx3sMzV6htQixSBCwZRhu7ofu04Ux8g/1DcwpbwpnPWrrnUJfP4WoBG0yKp6WA4JmSGZby3 rea2dvCCtGnClhtj4 Subject: Re: [musl] When to reclaim pages in __bin_chunk? On Fri, Jul 31, 2020 at 08:17:02AM +0800, Zhao Zhengyu wrote: > Hello, > > When chunks are merged, we use "(curr_size + pre_size) ^ pre_size > > pre_size" to decide whether to reclaim. I think this may be something > related to performance, but I can=E2=80=99t prove it. I want to know the > reason. > > Thank you! > > Zhengyu I asked that same question a while ago. For one, this was in the old malloc code, which is now usually no longer used. For two, this tries to figure out if adding current size to previous size rolls over into a new power of two. Usually, curr_size will be small and pre_size will be large. Therefore, adding the two will not change much about the high bits of pre_size, so due to the XOR operator, those bits will cancel out and the result will be smaller than pre_size. However, if the sum does roll over, then the sum has one bit set that isn't in pre_size and is larger than all the ones in pre_size. So the XOR can't cancel that bit, and the result of the XOR is greater than pre_size. Fundamentally, it is an optimized version of (a_clz(curr_size + pre_size) < a_clz(pre_size)). Ciao, Markus