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.133.124]) by sourceware.org (Postfix) with ESMTPS id 71A0E385840A for ; Mon, 10 Oct 2022 11:17:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 71A0E385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665400648; 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=8O7zAZ/fkIbzhpdtqsrl1xKEri8G2wUjfB2RsgRJD/o=; b=J4Dpmv5AWMixhM+ypPId41QcmlfpozczI6IJ9F/l7MM44OoONXVWr0+ugaWRjXuC4TrSAL yPd4hDOtmYQOp7cGFqbz+70h9dB//51vTDQTTI7XftLQaJ5y/659CjdFeexatxU9hc9cpJ rWID2eX0Vqio/O67mBK50z5t1DOBW2U= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-620-F3SUAG64MzqQ3zsUwAZyqA-1; Mon, 10 Oct 2022 07:17:24 -0400 X-MC-Unique: F3SUAG64MzqQ3zsUwAZyqA-1 Received: by mail-qk1-f197.google.com with SMTP id u6-20020a05620a430600b006e47fa02576so9124808qko.22 for ; Mon, 10 Oct 2022 04:17:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8O7zAZ/fkIbzhpdtqsrl1xKEri8G2wUjfB2RsgRJD/o=; b=ub+qAT6aT5gG8KFRYa08lE4LgYHI1acYfw0wo27TEqH97xYhczQi3LLUKnyLP5pQ4x bbvYB57MEpt+gqlcGqvuMB35sEEXdtAXGkmUssDoBmc1DRLLbVEHuNR7fPjBv8GJXe6i kPN3kpTmMKbufPR5Ni65DRWWX0m9KRGvq+5FF6qi7hTEr85pXPrk/69bjStgckl1oYnh k13jYeF8yyA2O2GeIjLjvMVMJTrDBokfy9kuO0UWiU19zfKk+E9bI+mihmodc3N7OFBt yVUpPVjHyE9fCOr8LOyyJwzTsoIujN2HKR1b8/8noEwdhORFGxlEee7iKFQpT21+ssQv nJTQ== X-Gm-Message-State: ACrzQf2RzHDdExOc1wWmsZV0gQdW0dvHF2Fly/4PAxqnbJvq1/O1ZYi+ +/m7pMOHr2sJ0S10XZP/XWOP8ZJbA+Aw5zJg/CFy17CXSIHq68SHvLt1MnljkKuUOzbyDHPdRAj xvYNYb6sBAcoAsLQr+DrZWhxOp468K2o= X-Received: by 2002:a05:622a:418a:b0:399:9cc6:8699 with SMTP id cd10-20020a05622a418a00b003999cc68699mr4386539qtb.122.1665400644478; Mon, 10 Oct 2022 04:17:24 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4Txf/Z80+KVD7Iodw/VEbHBIM12IQSRd1INc6rj/bgGYP2RzyBvV2l6LQ7BP0pTVTz3sWRBYdGW07lprg/zW4= X-Received: by 2002:a05:622a:418a:b0:399:9cc6:8699 with SMTP id cd10-20020a05622a418a00b003999cc68699mr4386531qtb.122.1665400644238; Mon, 10 Oct 2022 04:17:24 -0700 (PDT) MIME-Version: 1.0 References: <20221007155452.1299670-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Mon, 10 Oct 2022 12:17:13 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: Allow emergency EH alloc pool size to be tuned [PR68606] To: Richard Biener Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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 Mon, 10 Oct 2022 at 07:18, Richard Biener wrote: > > On Fri, Oct 7, 2022 at 5:55 PM Jonathan Wakely via Gcc-patches > wrote: > > > > This needs a little more documentation (see the TODO in the manual), > > rather than just the comments in the source. This isn't final, but I > > think it's the direction I want to take. > > > > -- >8 -- > > > > Implement a long-standing request to support tuning the size of the > > emergency buffer for allocating exceptions after malloc fails, or to > > disable that buffer entirely. > > > > It's now possible to disable the dynamic allocation of the buffer and > > use a fixed-size static buffer, via --enable-libstdcxx-static-eh-pool. > > This is a built-time choice that is baked into libstdc++ and so affects > > all code linked against that build of libstdc++. > > > > The size of the pool can be set by --with-libstdcxx-eh-pool-obj-count=N > > which is measured in units of sizeof(void*) not bytes. A given exception > > type such as std::system_error depends on the target, so giving a size > > in bytes wouldn't be portable across 16/32/64-bit targets. > > > > When libstdc++ is configured to use a dynamic buffer, the size of that > > buffer can now be tuned at runtime by setting the GLIBCXX_TUNABLES > > environment variable (c.f. PR libstdc++/88264). The number of exceptions > > to reserve space for is controlled by the "glibcxx.eh_pool.obj_count" > > and "glibcxx.eh_pool.obj_size" tunables. The pool will be sized to be > > able to allocate obj_count exceptions of size obj_size*sizeof(void*) and > > obj_count "dependent" exceptions rethrown by std::rethrow_exception. > > > > With the ability to tune the buffer size, we can reduce the default pool > > size. Most users never need to throw 1kB exceptions in parallel from > > hundreds of threads after malloc is OOM. > > But does it hurt? Back in time when I reworked the allocator to be less > wasteful the whole point was to allow more exceptions to be in-flight > during OOM shutdown of a process with many threads. It certainly hurts for small systems, but maybe we can keep the large allocation for 64-bit targets (currently 73kB) and only reduce it for 32-bit (19kB) and 16-bit (3kB IIRC) targets. And obviously if the new code to check an env var is backported, the defaults shouldn't be changed in the release branch. Just enable the new feature, but leave defaults the same. N.B. the C++ ABI actually requires that the emergency pool should block if too many threads try to access it at once. That would mean the program slows down drastically, but doesn't empty the pool and terminate if there are many threads all trying to throw on OOM. I'm not convinced blocking is the right default, but making it an option seems reasonable (I created PR107180 to track that). > So if we reduce the default buffer size that should be documented > in changes.html, maybe with a hint how to restore the old buffer size > (configury flags required or runtime ENV setting)? The git commit message gives the env setting to do that, and acinclude.m4 gives the configure option to do that. I can certainly add the info to changes.html where it's more likely to be noticed. > > Otherwise looks OK to me. Great, thanks for taking a look.