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 3C7643858C53 for ; Fri, 1 Mar 2024 08:44:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C7643858C53 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 3C7643858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709282665; cv=none; b=cIPgEhfwGEuDqb75HyfWeqvdc0iS8sjqZCadZuj3IKfvo1swJ8TqmBR5B6faLwaUz1fgOXw/2men4dLexKCKjOCwwC+F9g2eT5faJ8nGZmCeHK7hTsnKm0eHhOImoiIxY3Y+DG62j/6divYUTI7KUUFF/mG3xUx8JD7r8GrsDm0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709282665; c=relaxed/simple; bh=uIk6ssZNSSHCfKCsW3KEhHR33Dr/rxm01W01NsRsV40=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=tP6+CkXw9anWfhYhpyAOL7+jWxnR6JuEQyybU9Tyo2Ic5mI8f3LX3ip2VSoW2QZnNkMsf3vHH53Voa16WuB13V6NeG0/kt/FZuLrx+JoSEng84ROMIf/ghTtaP0GMql4RNAdOBQ9iWx2qqnYr6JNHPmEgFxz/qV34LsNGlwYmWA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709282660; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/cgPQ78oA40WfyRiGbou49fCKABEDseaiQKcq5IwSYE=; b=GLHwfFH1cB+q4u5ItgzGfaQy2KRN9BVGGYYYpPfd2kEqhKhPYsM933SQ5ymiW7y/wq78GT Ix4XQ4tal1c1HOl9kQ+N3dr3088H40Bi8iaDIZ9+YUGeUL5n2Zf4nvlLyfBiOiS13iNWrP MNlgYwVMM6W96t4dbwSSk6l2DAtuGco= 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-662-TxoThBgrN56-JeGEmk-_pw-1; Fri, 01 Mar 2024 03:44:15 -0500 X-MC-Unique: TxoThBgrN56-JeGEmk-_pw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (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 BF10183B86B; Fri, 1 Mar 2024 08:44:14 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.226.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2CC26200F829; Fri, 1 Mar 2024 08:44:14 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4218iC5s506362 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 1 Mar 2024 09:44:12 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4218iB5O506360; Fri, 1 Mar 2024 09:44:11 +0100 Date: Fri, 1 Mar 2024 09:44:11 +0100 From: Jakub Jelinek To: Tobias Burnus Cc: John David Anglin , Thomas Schwinge , John David Anglin , gcc-patches@gcc.gnu.org, Helge Deller Subject: Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests Message-ID: Reply-To: Jakub Jelinek References: <87sf1ax4aq.fsf@euler.schwinge.ddns.net> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 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: On Fri, Mar 01, 2024 at 09:29:01AM +0100, Tobias Burnus wrote: > John David Anglin wrote: > > On 2024-02-29 6:02 p.m., Thomas Schwinge wrote: > > > I wonder: shouldn't that cap at 50 threads happen inside libgomp, > > > generally, instead of per test case and user code (!)? > > > > Per my > > > understanding, OpenMP 'num_threads' specifies a *desired* number of > > > threads; the implementation may limit that value. > > Sounds like a good suggestion. > > I concur – if the hardware/OS doesn't support more. > > * * * > > However – for completeness and to correct a statement: While num_threads > specifies the desired number of threads, 'strict' will turn this into error > termination if the implementation cannot fulfilled the request. > > Namely, "if prescriptiveness is specified as 'strict' and Algorithm 11.1 > would result in a number of threads other than the value of the first item > of the _nthreads_ list then runtime error termination is performed." > > Note that 'strict' for num_threads is new in/since the OpenMP 6.0 draft > (TR11, I think) and not yet implemented in GCC. Also note that if hppa-linux really has such low thread limits, we can't simply try to add some hack in gomp_resolve_num_threads where it would lower the result if larger than 50, because if the limit is max 50 threads per process, just doing nested parallelism and asking for 25 threads in the outer and 4 in the inner in each will run over that limit, or teams 4 with max 25 threads in parallel inside of it, or user can use pthread_create in the process as well, etc. So, if at all possible, the best thing would be to change kernel so that the number of threads is limited just by available memory for stacks and user tweakable limit. E.g. on my ws I have cat /proc/sys/kernel/threads-max 253865 Isn't this just that you have 50 in there? Jakub