Date: Sat, 24 Mar 2012 00:52:29 -0700 (PDT) From: Sushanth Rai <sushanth_rai@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Improving gcore Message-ID: <1332575549.45446.YahooMailClassic@web180015.mail.gq1.yahoo.com> In-Reply-To: <20120323113841.GJ2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Fri, 3/23/12, Konstantin Belousov <kostikbel@gmail.com> wrote: 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. > > 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. Threads could have been running in user space and they are on the runq because their time slice expired or they yielded the CPU or got preempted. These 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 dealing with suspensions. >> 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 points > were suspension can be applied are essentially the same. I tend to agree with this. Thanks, Sushanth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1332575549.45446.YahooMailClassic>