From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 21:36:47 2008 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 C2C0D106566B for ; Mon, 21 Apr 2008 21:36:47 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9F6F58FC14 for ; Mon, 21 Apr 2008 21:36:47 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 21 Apr 2008 14:35:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,691,1199692800"; d="scan'208";a="375037413" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by orsmga001.jf.intel.com with ESMTP; 21 Apr 2008 14:36:39 -0700 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 14:36:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Apr 2008 14:36:45 -0700 Message-ID: In-Reply-To: <480CFA15.9050807@elischer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you really "sleep" when blocked on a mutex? Thread-Index: Acij7vMxWUHE/MjERKme35VKtWsswwACG1RQ References: <480CF0F2.20609@elischer.org> <480CFA15.9050807@elischer.org> From: "Murty, Ravi" To: "Julian Elischer" X-OriginalArrivalTime: 21 Apr 2008 21:36:46.0220 (UTC) FILETIME=[CC6FFCC0:01C8A3F7] Cc: freebsd-hackers@freebsd.org Subject: RE: Do you really "sleep" when blocked on a mutex? 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: Mon, 21 Apr 2008 21:36:47 -0000 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"