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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id D36B8384C004 for ; Tue, 22 Sep 2020 13:24:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D36B8384C004 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-116-W7bwveGZN2KaPYMpM74pxw-1; Tue, 22 Sep 2020 09:24:44 -0400 X-MC-Unique: W7bwveGZN2KaPYMpM74pxw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 402571007464; Tue, 22 Sep 2020 13:24:43 +0000 (UTC) Received: from redhat.com (ovpn-113-119.rdu2.redhat.com [10.10.113.119]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE48E60CCC; Tue, 22 Sep 2020 13:24:42 +0000 (UTC) Date: Tue, 22 Sep 2020 09:24:40 -0400 From: Marek Polacek To: Martin =?utf-8?B?TGnFoWth?= , GCC Patches , Jan Hubicka Subject: Re: [PATCH 2/3] Use MiB unit when displaying memory allocation. Message-ID: <20200922132440.GN5926@redhat.com> References: <1c922586-9b54-61cb-473b-455455413dd2@suse.cz> <20200901140432.GD13145@kam.mff.cuni.cz> <6da4010f-7677-e5a4-5471-8cd66f25ca35@suse.cz> <20200922130208.GM5926@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200922130208.GM5926@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Spam-Status: No, score=-9.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_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 13:24:48 -0000 On Tue, Sep 22, 2020 at 09:02:08AM -0400, Marek Polacek via Gcc-patches wrote: > On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote: > > On 9/22/20 9:47 AM, Christophe Lyon wrote: > > > On Wed, 2 Sep 2020 at 15:29, Martin Liška wrote: > > > > > > > > On 9/1/20 4:04 PM, Jan Hubicka wrote: > > > > > > The patch is about usage of MiB in memory allocation reports. > > > > > > I see it much better readable than values displayed in KiB: > > > > > > > > > > > > Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB} > > > > > > Reading the symbol table: > > > > > > Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB} > > > > > > Reading summaries: {GC 27 MiB} {heap 15 MiB} {GC 27 MiB} {heap 15 MiB} {GC 27 MiB} {heap 15 MiB} {GC 27 MiB} {heap 15 MiB} {GC 27 MiB} {heap 15 MiB} {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} {heap 15 MiB} {GC 30 MiB} > > > > > > Merging symbols: {heap 15 MiB}Materializing decls: > > > > > > {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} {heap 15 MiB} > > > > > > Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns) > > > > > > > > > > One problem I see here is that while it is OK for Firefox builds it is > > > > > bit too coarse for smaller testcases where the memory use is still > > > > > importnat. I guess we may just print KBs before the large gets too > > > > > large, just like norton commander does? :) > > > > > > > > Sure, let's do it using SIZE_AMOUNT macro. > > > > > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > > > > > > > > Hi, > > > > > > This change is causing gcc.dg/timevar[12].C to fail randomly, eg: > > > FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors) > > > Excess errors: > > > phase opt and generate : 0.00 ( 0%) 0.00 ( 0%) > > > 0.01 ( 50%) 8904 ( 0%) > > > callgraph construction : 0.00 ( 0%) 0.00 ( 0%) > > > 0.01 ( 50%) 4096 ( 0%) > > > > > > because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests > > > now use dg-prune-output "k" and dg-prune-output " 0 " > > > which is not enough. > > > > > > Can you fix this? > > > > Sorry for the breakage. I hope Marek has a fix that he'll install. > > Should be fixed now! Ah, timevar1.C has the same problem. Will fix that one now too. Marek