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 83EFF385782C for ; Wed, 18 May 2022 10:19:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83EFF385782C Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-90-z4Tb8yeePnKRl7DTHPvFYA-1; Wed, 18 May 2022 06:19:17 -0400 X-MC-Unique: z4Tb8yeePnKRl7DTHPvFYA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A6DBD3C16187; Wed, 18 May 2022 10:19:16 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.89]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9D84E1121314; Wed, 18 May 2022 10:19:15 +0000 (UTC) From: Florian Weimer To: Len Brown via Libc-alpha Cc: "H.J. Lu" , Len Brown Subject: Re: Pthread QOS interface References: Date: Wed, 18 May 2022 12:19:13 +0200 In-Reply-To: (Len Brown via Libc-alpha's message of "Tue, 17 May 2022 13:59:05 -1000") Message-ID: <87v8u36t3y.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2022 10:19:21 -0000 * Len Brown via Libc-alpha: > I have a more specific question. > > Can we implement EXACTLY the same interface as Apple has -- so a > cross-platform application doesn't have to change? (I see an Apple > source license on that qos.h -- is that an issue with an API?) > > (I think the answer about the scheduling interface is simply "yes", we > can add new Linux-specific flags to the existing sched_setattr(2) -- > but ideally applications should be using a more portable interface, > rather than directly invoking linux-specific system calls) Isn't this traditionally handled by cgroups and/or rtkit? If we can get a syscall interface for this from the kernel, we could add something in parallel to that to glibc, but I doubt it would have the same semantics as the Darwin interface even if we keep the API the same. For example, Linux may require different permissions for making these changes, and apply them to different aspects of system behavior (CPU, mass storage I/O, memory bandwidth, network traffic). Thanks, Florian