From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752501AbdHBSQH (ORCPT ); Wed, 2 Aug 2017 14:16:07 -0400 Received: from mail-qt0-f176.google.com ([209.85.216.176]:37393 "EHLO mail-qt0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752389AbdHBSQF (ORCPT ); Wed, 2 Aug 2017 14:16:05 -0400 Date: Wed, 2 Aug 2017 11:16:00 -0700 From: Tejun Heo To: Peter Zijlstra Cc: lizefan@huawei.com, hannes@cmpxchg.org, mingo@redhat.com, longman@redhat.com, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, efault@gmx.de, torvalds@linux-foundation.org, guro@fb.com Subject: Re: [PATCH 2/2] sched: Implement interface for cgroup unified hierarchy Message-ID: <20170802181600.GJ2311718@devbig577.frc2.facebook.com> References: <20170720184808.1433868-1-tj@kernel.org> <20170720184808.1433868-3-tj@kernel.org> <20170729091707.lobbicnw253wzltu@hirez.programming.kicks-ass.net> <20170801201745.GA2311718@devbig577.frc2.facebook.com> <20170801214038.sp4lw6lrnl3votte@hirez.programming.kicks-ass.net> <20170802154135.GI2311718@devbig577.frc2.facebook.com> <20170802160511.cb7yl65t4nmctf3y@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170802160511.cb7yl65t4nmctf3y@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Peter. On Wed, Aug 02, 2017 at 06:05:11PM +0200, Peter Zijlstra wrote: > > * The stat file is sampling based and the usage files are calculated > > from actual scheduling events. Is this because the latter is more > > accurate? > > So I actually don't know the history of this stuff too well. But I would > think so. This all looks rather dodgy. I see. > > * Why do we have user/sys breakdown in usage numbers? It tries to > > distinguish user or sys by looking at task_pt_regs(). I can't see > > how this would work (e.g. interrupt handlers never schedule) and w/o > > kernel preemption, the sys part is always zero. What is this number > > supposed to mean? > > For normal scheduler stuff we account the total runtime in ns and use > the user/kernel tick samples to divide it into user/kernel time parts. > See cputime_adjust(). > > But looking at the cpuacct I have no clue, that looks wonky at best. > > Ideally we'd reuse the normal cputime code and do the same thing > per-cgroup, but clearly that isn't happening now. > > I never really looked further than that cpuacct_charge() doing _another_ > cgroup iteration, even though we already account that delta to each > cgroup (modulo scheduling class crud). Yeah, it's kinda silly. I'll see if I can just kill cpuacct for cgroup2. Thanks. -- tejun