Date: Mon, 21 Apr 2008 14:36:45 -0700 From: "Murty, Ravi" <ravi.murty@intel.com> To: "Julian Elischer" <julian@elischer.org> Cc: freebsd-hackers@freebsd.org Subject: RE: Do you really "sleep" when blocked on a mutex? Message-ID: <AEBCFC23C0E40949B10BA2C224FC61B0070446F0@orsmsx416.amr.corp.intel.com> In-Reply-To: <480CFA15.9050807@elischer.org> References: <AEBCFC23C0E40949B10BA2C224FC61B00704441C@orsmsx416.amr.corp.intel.com> <480CF0F2.20609@elischer.org> <AEBCFC23C0E40949B10BA2C224FC61B00704452C@orsmsx416.amr.corp.intel.com> <480CFA15.9050807@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
That's actually what I was trying to get to. If I look at vm_daemon(), it checks to see if every thread of the process is running, on the runq or sleeping. If any threads fails the condition - and I can think of the case where a thread is blocked waiting for a lock - it is not a target to be swapped out. I guess this means that if a thread is holding a lock, it can be swapped out. How does this guarantee that the thread is not holding a kernel lock? Why don't they allow threads waiting for a lock (blocked threads/processes) to be swapped out? Related question: how can a process/thread running on a CPU be swapped out, do they suspend the threads before they pull out memory from underneath them? Thanks Ravi -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 Sent: Monday, April 21, 2008 1:33 PM To: Murty, Ravi Cc: freebsd-hackers@freebsd.org Subject: Re: Do you really "sleep" when blocked on a mutex? Murty, Ravi wrote: > Fundamentally it seems that they both come down to inhibiting the thread > and putting them on some queue before calling mi_switch(). But when a > thread is woken up from a sleep, setrunnable is called and it checks to > see if the process is swapped out. No such check is made when a thread > is waiting for a lock (I'm wondering if this is related to how long they > block before becoming runnable which might cause a swapout in one case > and no swapout in the other case?) blocking processes/threads are not eligible to be swapped out. >=20 > Ravi >=20 >=20 > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org]=20 > Sent: Monday, April 21, 2008 12:54 PM > To: Murty, Ravi > Cc: freebsd-hackers@freebsd.org > Subject: Re: Do you really "sleep" when blocked on a mutex? >=20 > Murty, Ravi wrote: >> Hello, >> >> =20 >> >> When a thread cannot get a mutex (default mutex) and needs to be >> blocked, is it really put to sleep? From looking at the code it > appears >> that it is inhibited (TD_SET_LOCK) but isn't really put to sleep. >> > it really has two answers. >=20 > 1/ sleep has a lot of historical baggage and is expected to work in=20 > certain ways. >=20 > 2/ there is a semantic difference between a sleep > (which may sleep for an unbounded time) and being descheduled for > a blocking lock, (Which is supposed to have a guaranteed "shortness" > of duration. >=20 > Because sleeps 'may never return' (in the short term) there is a > limit of what you may hold when sleeping. In blocking locks > you may hold other resources, with the expectation that the > other threads will be following the correct locking order and that > the nesting of held resources will be safe, because you will > only be blocked for a moment. >=20 > The lowest leven code is the same of course.. things are put on the=20 > run queue, or not.. Having different higher layers allows us to do > various sanity checks and to enforce the different behaviour. >=20 >=20 >> =20 >> >> 1. Why isn't it put to sleep - why can't it be treated the same? >> 2. The eventual question I am trying to answer is the difference >> between setrunnable() and setrunqueue() - this one simply finds a slot >> in the ksegrp and a runq to add the KSE/td. But setrunnable() also >> checks to see if the process is in memory (PS_INMEM) before calling >> sched_wakeup which eventually calls setrunqueue()? Why doesn't >> setrunqueue have to worry about the possibility that the process may >> have been swapped out while it was waiting to become runnable? >> >> =20 >> >> Thanks >> >> Ravi >> >> =20 >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEBCFC23C0E40949B10BA2C224FC61B0070446F0>