From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753192AbbJYKrM (ORCPT ); Sun, 25 Oct 2015 06:47:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55538 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751317AbbJYKrL (ORCPT ); Sun, 25 Oct 2015 06:47:11 -0400 Subject: Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy To: "Theodore Ts'o" , Ingo Molnar , Linus Torvalds , Tejun Heo , Mike Galbraith , Paul Turner , Peter Zijlstra , Ingo Molnar , Johannes Weiner , Li Zefan , cgroups , LKML , kernel-team , Andrew Morton References: <20150912144007.GA8942@htj.duckdns.org> <20151001184629.GB26498@mtj.duckdns.org> <20151023222110.GA4390@mtj.duckdns.org> <1445661367.3218.62.camel@gmail.com> <20151025021829.GA15471@mtj.duckdns.org> <20151025093331.GA4834@gmail.com> <20151025104145.GE27558@thunk.org> From: Florian Weimer Message-ID: <562CB328.3090906@redhat.com> Date: Sun, 25 Oct 2015 11:47:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151025104145.GE27558@thunk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/25/2015 11:41 AM, Theodore Ts'o wrote: > On Sun, Oct 25, 2015 at 10:33:32AM +0100, Ingo Molnar wrote: >> >> Hm, that's weird - all our sched_*() system call APIs that set task scheduling >> priorities are fundamentally per thread, not per process. Same goes for the old >> sys_nice() interface. The scheduler has no real notion of 'process', and certainly >> not at the system call level. >> > > I suspect the main issue is that the games programmers were trying to > access it via libc / pthreads, which hides a lot of the power > available at the raw syscall level. This is probably more of a > "tutorial needed for userspace programmers" issue, at a guess. If this refers to the lack of exposure of thread IDs in glibc, we are willing to change that on glibc side. The discussion has progressed to the point where it is now about the question whether it should be part of the GNU API (like sched_setaffinity), or live in glibc as a Linux-specific extension (like sched_getcpu). More input is certainly welcome. Old concerns about support for n:m threading implementations in glibc are no longer relevant because too much code using well-documented interfaces would break. Florian