NetBSD Problem Report #51937

From dholland@macaran.eecs.harvard.edu  Wed Feb  1 22:45:57 2017
Return-Path: <dholland@macaran.eecs.harvard.edu>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 8E8EC7A269
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  1 Feb 2017 22:45:57 +0000 (UTC)
Message-Id: <20170201224457.097DD6E273@macaran.eecs.harvard.edu>
Date: Wed,  1 Feb 2017 17:44:41 -0500 (EST)
From: dholland@eecs.harvard.edu
Reply-To: dholland@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: getrusage(2) should supply blocking time
X-Send-Pr-Version: 3.95

>Number:         51937
>Category:       kern
>Synopsis:       getrusage(2) should supply blocking time
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 01 22:50:00 +0000 2017
>Originator:     David A. Holland
>Release:        NetBSD 7.99.44 (details irrelevant)
>Organization:
>Environment:
System: NetBSD macaran 7.99.44 NetBSD 7.99.44 (MACARAN) #40: Thu Dec 8 17:57:53 EST 2016 dholland@macaran:/usr/src/sys/arch/amd64/compile/MACARAN amd64
Architecture: x86_64
Machine: amd64
>Description:

getrusage(2) supplies the time spent executing in userspace and in the
kernel. One can, and time(1) does, readily supplement that with the
total elapsed wall clock time.

Historically people often compare the elapsed wall lcock time to the
execution time to figure out how much time is spent waiting in the
kernel. This has never been a particularly reliable method to begin
with, and with a multithreaded process it breaks down entirely.

In a multithreaded process the total execution time reported is the
sum over all threads, but unless you know how many cores were running
those threads *and* the history of thread migration between cores,
which you don't, you can't deduce how much time was spent waiting.

If you pin every thread to a core you might be able to reconstruct
some information, but that (a) isn't always possible, (b) isn't always
advisable, and (c) seems chancy.

It ought to be straightforward for the kernel to collect and report
wait times; it just doesn't.

>How-To-Repeat:
n/a
>Fix:
bikeshed first, then code away

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.