From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 2F5073858C35 for ; Mon, 27 May 2024 13:06:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F5073858C35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2F5073858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716815169; cv=none; b=FD2o15g+V9WbeiC9UeWeGC82/CBOdjsT1mcxKiJS7I9yUzlVOHKJQGP5763P0m5k67vIWRvn9969vzuxznUXopvEtjdfLHRS8Mf4+5BZ+zgvPnybl78nASCNLAoslI1zGNNQovvE0Cuy7pr4b0fXxyPJxUxPr7tj/3tTMQQXDGU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716815169; c=relaxed/simple; bh=El0d5LFDyJZ3GSOvYYCdPPiNANN9hwfY9xQTD1ivuWk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=nSoNCZIt40lXeRftc4lJ9AjpVJXNk+RC/0Q/qigSoHRtRWfzbzuD0Zdxinn5SyrriVs7VdNLbskN3v5GALtZxiXtIppD86mh8274Ff+bMa32k4NG5+HBYjLfUqEUeT16CbwrEoLxlvQAAEuJmoEtEx1HHqYJwnuRHnrzI7nVv5Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716815167; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YjXhcCDS1Z1MYK/bkCz/niCwgTbW58I7qHbdL2k9EZM=; b=S5LjqZTj2lBmz45V3ZxG2CNQpQmXUm/ucEYZRZ7+rZksb8bGt8BeYwo3EJYoDedOVviaUM JQoKBNU8PPGmxctbACyklZYTNFkY7CQ+BRBRHbSeF5p4v3PpX+0lZxSfMQQtZCFNUYsulv GdghOyt8O9NMNF3yh3baT1GuikIRlyg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-347-jDYRt9AUNuGWTFCv1cyjTg-1; Mon, 27 May 2024 09:06:04 -0400 X-MC-Unique: jDYRt9AUNuGWTFCv1cyjTg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E5018184868B; Mon, 27 May 2024 13:06:03 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.98]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 65171200B3A1; Mon, 27 May 2024 13:06:03 +0000 (UTC) From: Florian Weimer To: Eric Wong Cc: libc-alpha@sourceware.org Subject: Re: [RFT] malloc: reduce largebin granularity to reduce fragmentation In-Reply-To: <20240409093352.M757838@dcvr> (Eric Wong's message of "Tue, 9 Apr 2024 09:33:52 +0000") References: <20240409093352.M757838@dcvr> Date: Mon, 27 May 2024 15:06:02 +0200 Message-ID: <87r0dnz9ol.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: * Eric Wong: > Anybody volunteers to help test and get reproducible results for > this? Thanks in advance. > > Testing and getting reproducible results is proving extremely > expensive due to trace sizes and CPU usage required to handle > my existing web/IMAP/NNTP-facing traffic. > > But the theory works in my mind and could be a solution to a > problem I've noticed for decades at this point across long-lived > Ruby and Perl web daemons. > > I'm also considering having this as a tunable and mallopt(3). > > And perhaps limiting the alignment to pagesize can work, because > 20% of a large sliding mmap_threshold on 64-bit is several > megabytes... I looked at the patch and you did not eliminate the mostly-unused bins. (They can still get used due to fragmentation.) So you get a strange conflation of various effects with this patch. If we're serious about this, we need to test something that reduces the bin count. I'm not sure if it makes senst to test this current version. Thanks, Florian