From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 19:52:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3523316A4CE; Wed, 12 Jan 2005 19:52:21 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14DC343D5A; Wed, 12 Jan 2005 19:52:21 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id D9BD17A403; Wed, 12 Jan 2005 11:52:20 -0800 (PST) Message-ID: <41E57FF4.90403@elischer.org> Date: Wed, 12 Jan 2005 11:52:20 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <20050109011132.GJ39552@cirb503493.alcatel.com.au> <41E0C02F.60100@freebsd.org> <20050109101529.GM39552@cirb503493.alcatel.com.au> <9D0B94DA-63E2-11D9-A25E-000393921CC4@baldwin.cx> In-Reply-To: <9D0B94DA-63E2-11D9-A25E-000393921CC4@baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Peter Jeremy cc: freebsd-current@freebsd.org cc: Scott Long Subject: Re: bus_dmamem_alloc() can't handle large NOWAIT requests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 19:52:21 -0000 John Baldwin wrote: > Unforunately, "sleep" is a bit of an overloaded term in the kernel. > Blocking on a mutex is not considered a "sleep" quite like msleep() or > cv_wait() in that a mutex will eventually be released (barring an > infinite loop bug) and thus a thread blocked on a lock won't sleep > forever. msleep() and cv_wait() on the other hand do not have the > same guarantee. M_NOWAIT means that msleep() and cv_wait() won't be > called; it is ok to block on a mutex with M_NOWAIT however. I tried > to explain this difference in semantics some in the glossary of the > SMP chapter in the kernel devbook. The problem is that people may think about a call with M_NOWAIT for different reasons. Sometimes it is to ensure that the response time is limitted, even if that means that an error may be returned, while others may call it because they feel it stops the possibility of recursion or some other interference.. The 2nd will not work in the current scheme where a mutex may block the thread. The distinction needs to be drawn between "don't go away for a long time" and "don't switch to any other thread".