From owner-freebsd-questions@FreeBSD.ORG Wed Jan 19 01:01:18 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AA4D106564A for ; Wed, 19 Jan 2011 01:01:18 +0000 (UTC) (envelope-from materribile@yahoo.com) Received: from nm13.bullet.mail.sp2.yahoo.com (nm13.bullet.mail.sp2.yahoo.com [98.139.91.83]) by mx1.freebsd.org (Postfix) with SMTP id 454A18FC0A for ; Wed, 19 Jan 2011 01:01:18 +0000 (UTC) Received: from [98.139.91.69] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 19 Jan 2011 01:01:17 -0000 Received: from [98.139.91.21] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 19 Jan 2011 01:01:17 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 19 Jan 2011 01:01:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 790185.13111.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 98577 invoked by uid 60001); 19 Jan 2011 01:01:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295398876; bh=cJ53bDQGxV3Ce3GmGON7CfOJj2L5/7KGKl8oubSuHz8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cfSSIw8qoFh6NP7SbkCqb1NQnnyOTjAQfjK2EVAXrx2+5V8p4Zh/zJ5kgNNBH8zM6EkiI+ANAxLts005DLMdunJENTmYCKmd5UGB4cIIzttzZiZcHaEmRT3s+7WocaUngXfyyGFPIaLBrbvB2yU8YGlUSRxZpr//TlniAqcVwwQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hUlQnOMe1AbOHBvjDuq2WN/BhQMxRwCT0JeGx84DVxLGmBtyXzADIQCcjKH9Pys2a6qFJ/rJBTPOfwdH5qrTTbdanbMbEAs4dS7FEhBEe39nNvAKJpJiH6stzglZekfyKqo2uIAwvu1gxKMsJwp0ADaB3Z8enRAPvWeuZAEzxAw=; Message-ID: <35110.88084.qm@web110316.mail.gq1.yahoo.com> X-YMail-OSG: 2g2sCg4VM1n.Z_rMh1olwrrHZoBZ574UvsgPCgIGnkCtiVF 4fNPhfNX_8nI17LzIeIZw2_wUMGbNcXrSsO_MrW3QnTjRkpoJYqaBT4XeDAP zE_UYtt.mFMWl5QCNVkCI6LCltw9zGFcVF7WQrkqdlhGN5zIioxUZ8c57m3O f7JT2qA2OXo8XTuf9HlW_Gu.p5u7puVM79oyIlx1LhiM8VYxYnb8scjt4HoG dUcl18HZ.OB2dgbPsGh744AwqWo4yhX8sffezpJonQ7VdQnva2RK6m77U_KE Nli.cfaa0gE11Q_DIED8fWNZWnBpgQBd.gYu.HIPIq4mLZMg5tFfS532cOfq tlh_d_iQhQ17yTvYCeIIGzTPXd7_mBSCyZCE3UJxSJ44oc1_lg_bYRKl3.5u CNR6eJi3C618x Received: from [24.228.57.153] by web110316.mail.gq1.yahoo.com via HTTP; Tue, 18 Jan 2011 17:01:15 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Tue, 18 Jan 2011 17:01:15 -0800 (PST) From: Mark Terribile To: Chuck Swiger In-Reply-To: <9319A30D-9AC6-46BB-B7EE-A476C88A05ED@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-questions@freebsd.org Subject: Re: rusage and pthreads X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 01:01:18 -0000 Chuck,=0A=0A> > I'm trying to figure out the interactions between=0A> rusag= e and pthreads.=0A> =0A> There largely isn't any-- struct rusage is per-pro= cess, not=0A> per thread.=0A =0A> > Peeking around in the kernel (7.2) I se= e updates=0A> occurring in various places.=A0 kern_clock.c, for=0A> instanc= e, appears to increment the memory occupancy (*rss)=0A> counters.=A0 This w= ould make it appear that every thread=0A> gets part of the count, but also = that only the process that=0A> happens to have the CPU at that moment gets = its count=0A> updated, even if it holds the memory.=A0 Am I misreading=0A> = this?=0A> =0A> Nope.=A0 statclock() is fired off periodically (with=0A> som= e fuzz, to avoid clever games by processes trying to=0A> avoid being sample= d) to update the stats for the currently=0A> running process.=0A> =0A> > An= d the context switch counters also appear to be=0A> updated per-thread, but= in mi_switch(), in=0A> kern_synch.c.=A0 Is this true?=0A> =0A> Probably.= =0A> =0A> > If the answer is "yes, it's per-thread", then how does=0A> a pr= ocess report its usages without putting the requisite=0A> code in each thre= ad, along with the machinery to divert from=0A> whatever the thread is doin= g (even waiting on I/O) to get=0A> the report at (nearly) the same time in = all threads?=0A> =0A> The process doesn't have userland threads updating th= is=0A> information.=A0 The kernel keeps track of it, and it=0A> updates the= information periodically when the scheduler does=0A> context switches, whe= n statclock() fires off, when disk I/O=0A> completes, etc.=0A=0AI'm looking= at kern_clock.c::statclock(int usermode)=0A=0AThe code in question begins= =0A=0A struct rusage* ru;=0A struct vmspace* vm;=0A st= ruct thread *td;=0A struct proc *p;=0A ...=0A td =3D curthre= ad;=0A p =3D td->td_proc;=0A=0Aand continues further down=0A=0A = ru =3D &td->td_ru;=0A ru->ru_ixrss +=3D pgtok(vm->vm_tsize);=0A = ru->ru_idrss +=3D pgtok(vm->vm_dsize);=0A ru->ru_isrss +=3D pg= tok(vm->vm_ssize);=0A=0AThis looks to me like it's accumulating the data in= per-thread counters. What's more, it's consistent with what I'm seeing on= the user side. Note that this is 7.2; if 8.x behaves differently I'd like= to know.=0A=0A Mark Terribile=0A=0A=0A=0A