From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) by sourceware.org (Postfix) with ESMTPS id 101013858C2D for ; Wed, 18 May 2022 20:55:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 101013858C2D Received: by mail-ua1-f52.google.com with SMTP id f13so1277558uax.11 for ; Wed, 18 May 2022 13:55:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5mU2AfYcINWzOS9POVeV2JCVXCmqi5GVjPH+e1LPPqQ=; b=R81AwbAbG/M3OvMMdrutj1nXsrWqwUE0tPsCY9/4e2M36IFPltMCbDNvkNPEWjGKe6 W/wpHUtpkWYpQVWztlSnYM7Asj8yc64w/DwuaC8A85MRWcxgHV3qRkVZFP33fBO+rsTX cLptQk7zw2Sm2VVImP0CPJWpneda+qpGup8ArVh5PjOB/anhtxeqDDY9CepIm0cZJ5ri u7M8VkQNCQHRLi13+p2M7APVvUX7NYnJk/LeMHb6MQhGmr+SCXSS43EZfr5XNqGXBS5T eKcq182etdijVEeSkGdHdrw6iqmDslCkm3RRuE+gn1dd0UGHUlqmvxKzffiafD4zev7w Mz9A== X-Gm-Message-State: AOAM532qz8pZhm9EwwHTejMGLb/6Mvj4C+Pxt8fpTV1x79HiA6qT4vRc BxthdUQ6MgMtbzxaIDfgNq9ewmKtrVeA+nLfBmRtYSWsSUc= X-Google-Smtp-Source: ABdhPJwjoec/I7pM1qxfYDkE23wJ1mwRiH2knsIKvDnumtR3KhFaJ5LGVPDVd6irc9ssW+5CCh5hdXwwwESwFoTC4Bs= X-Received: by 2002:ab0:5b4d:0:b0:35d:2f9c:f01 with SMTP id v13-20020ab05b4d000000b0035d2f9c0f01mr831635uae.86.1652907347336; Wed, 18 May 2022 13:55:47 -0700 (PDT) MIME-Version: 1.0 References: <87v8u36t3y.fsf@oldenburg.str.redhat.com> In-Reply-To: <87v8u36t3y.fsf@oldenburg.str.redhat.com> From: Len Brown Date: Wed, 18 May 2022 10:55:36 -1000 Message-ID: Subject: Re: Pthread QOS interface To: Florian Weimer Cc: Len Brown via Libc-alpha , "H.J. Lu" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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 20:55:49 -0000 On Wed, May 18, 2022 at 12:19 AM Florian Weimer wrote: > > 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?) > Isn't this traditionally handled by cgroups and/or rtkit? Yes, cgroups have been used to address some of this in the past. But cgroups have their benefits and weaknesses. The fundamental problem with cgroups is that somebody with a lot of knowledge has to manage both what they do, and what tasks belong to what group. Further, cgroups only work in a strict hierarchy. An API, on the other hand, allows a task to say something that it may actually know about -- what kind of task it is -- and not require it or anybody outside the kernel to know, for example, how the scheduler may want to schedule a background task relative to other tasks at a particular time. What is rkit? > 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). Yes, this is what I propose. I can supply/propose the system call interface. My question is if there is hope that pthreads can be plumbed to talk to it. The semantics of the Darwin interface are documented, and Indeed, I propose we match them EXACTLY. For that is what the multi-platform app wants. Of course, under the hood, the implementation will be entirely different, as the OS under the hood is entirely different, but he APP will be giving each OS exactly the same message to work with. Yes, under the hood on Linux, some scheduler attributes require more than default permission. We can grant that permission in the important cases. We can also still make a positive difference in places where no permission is required. thanks, -Len Brown, Intel