From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 24 08:01:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7DFB106566B for ; Sat, 24 Mar 2012 08:01:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 365968FC1C for ; Sat, 24 Mar 2012 08:01:33 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2O81UaM017817; Sat, 24 Mar 2012 10:01:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2O81TbA013000; Sat, 24 Mar 2012 10:01:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2O81Twn012999; Sat, 24 Mar 2012 10:01:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 Mar 2012 10:01:29 +0200 From: Konstantin Belousov To: Sushanth Rai Message-ID: <20120324080129.GT2358@deviant.kiev.zoral.com.ua> References: <20120323113841.GJ2358@deviant.kiev.zoral.com.ua> <1332575549.45446.YahooMailClassic@web180015.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NYBcJxZzAu4ovuvd" Content-Disposition: inline In-Reply-To: <1332575549.45446.YahooMailClassic@web180015.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Improving gcore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 08:01:35 -0000 --NYBcJxZzAu4ovuvd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 24, 2012 at 12:52:29AM -0700, Sushanth Rai wrote: >=20 >=20 > --- On Fri, 3/23/12, Konstantin Belousov wrote: >=20 >=20 > Can we > > > safely remove them out of the runq ? > > No, since thread on runq shall be considered the same as the > > thread > > actually executing on CPU. It is unsafe to suspend the > > thread in this > > state, due to it potentially owning a kernel resource. > >=20 > > It the thread on runq but not on CPU is set up to return to > > usermode > > 'immediately' after putting back on CPU, then normal AST > > check would > > cause its suspend. >=20 > Threads could have been running in user space and they are on the runq be= cause their time slice expired or they yielded the CPU or got preempted. Th= ese threads will only notice the suspension when they enter the kernel via = syscall or trap. If we can identify that a thread got switched-out for any = of these reasons then it's reasonable to remove it from the runq when deali= ng with suspensions. >=20 No, I mentioned exactly this in paragraph you replied to. To actually start executing from runq, thread needs to transition from kernel to userspace (in other words, thread appears on runq due to interrupt, thus entering kernel space). On the kernel->user transition, the thread will be suspended in AST handler. So, if pending AST catched usermode thread on runq, no single usermode instruction is executed by the thread before suspension. > >> approach and ofcourse it is missing details at this point. The idea > >> again is to suspend all threads as quickly as possible. > > I do not see how this would provide any significant difference comparing > > with SIGSTOP delivery. The points were signals are checked and the poin= ts > > were suspension can be applied are essentially the same. >=20 > I tend to agree with this. >=20 > Thanks, > Sushanth >=20 --NYBcJxZzAu4ovuvd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9tf1kACgkQC3+MBN1Mb4jUagCggAiHhGjluqs25dH1DuJM1Occ aTkAnAwkD5VqXM67QGjUcugkMr0oKyKL =h8ru -----END PGP SIGNATURE----- --NYBcJxZzAu4ovuvd--