From owner-freebsd-hackers@FreeBSD.ORG  Wed Feb 23 14:00:29 2005
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8E83816A4D0; Wed, 23 Feb 2005 14:00:29 +0000 (GMT)
Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua
	[195.245.194.142])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id BB0A443D1D; Wed, 23 Feb 2005 14:00:27 +0000 (GMT)
	(envelope-from simon@comsys.ntu-kpi.kiev.ua)
Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua
	[10.18.54.109])	(authenticated bits=0)j1NE3RcP085943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Feb 2005 16:03:27 +0200 (EET)
Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000)
	id 9FEC4110; Wed, 23 Feb 2005 16:00:17 +0200 (EET)
Date: Wed, 23 Feb 2005 16:00:17 +0200
From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua>
To: John Baldwin <jhb@freebsd.org>
Message-ID: <20050223140017.GA256@pm514-9.comsys.ntu-kpi.kiev.ua>
References: <000801c51327$0e2bf020$58e243a4@ash>
	<20050215132020.GA376@pm514-9.comsys.ntu-kpi.kiev.ua>
	<200502221534.41979.jhb@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200502221534.41979.jhb@FreeBSD.org>
User-Agent: Mutt/1.4.2.1i
X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.0.1
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on 
	comsys.ntu-kpi.kiev.ua
X-Virus-Scanned: ClamAV 0.82/707/Thu Feb 17 00:00:07 2005 on
	comsys.ntu-kpi.kiev.ua
X-Virus-Status: Clean
cc: freebsd-hackers@freebsd.org
cc: Ashwin Chandra <ashcs@ucla.edu>
Subject: Re: Kernel monitor, the return
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2005 14:00:29 -0000

On Tue, Feb 22, 2005 at 03:34:41PM -0500, John Baldwin wrote:
> 
> You don't need sched_lock to check PS_INMEM, proc lock is sufficient
> (PS_INMEM is magic this way).

I suggested the author of the original letter to get lock on sched_lock,
because statclock() modifies ru_idrss and ru_isrss values and that
values are read in that kproc.  Having read some code in the kernel,
now I think that lock on sched_lock is needed only before reading
ru_idrss and ru_isrss for current thread.  Am I right?  (at least
getrusage() does in this way.)

In private letters we found that it is better to use _PHOLD/_PRELE
for that task.

> If you did though, you would lock proc first, then sched_lock.
> You can _not_ lock a regular mutex (proc lock) after a spin 
> mutex (sched_lock) or you can deadlock.

Thanks... mutex(9) also says about this.  I've just looked at sources
for mtx_lock_spin/unspin and for better understanding of meaning of
the sentence you wrote.