Date: Sat, 24 Mar 2012 10:01:29 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Sushanth Rai <sushanth_rai@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Improving gcore Message-ID: <20120324080129.GT2358@deviant.kiev.zoral.com.ua> In-Reply-To: <1332575549.45446.YahooMailClassic@web180015.mail.gq1.yahoo.com> References: <20120323113841.GJ2358@deviant.kiev.zoral.com.ua> <1332575549.45446.YahooMailClassic@web180015.mail.gq1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kostikbel@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120324080129.GT2358>