From owner-svn-src-projects@FreeBSD.ORG Tue Oct 15 08:17:05 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 78CF95A8; Tue, 15 Oct 2013 08:17:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 946122BAD; Tue, 15 Oct 2013 08:17:04 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id d10so3927781eaj.12 for ; Tue, 15 Oct 2013 01:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=N4CaUN0F6Zz7Qc4ZTCGey49Y1V0WneWg5/y89hT7rNk=; b=SXrx1iEvn5rEtCUsrNuFfFTdBU6YNLGOdD6PPasQs/HjHRmx+DkZeJqjbb30EeirSO mIjhStf0+DokQpJpCB9E1iYy6/g3kiEESYvqe9ohIUiO7iT0BUIr+y+9rH2wsVFraTvf MWSmtG8w4X8W+3myLXptLLzO5ndl/Du4d2NCFhSmN7by9KroLAj2+rek5LNEN/6qtXnv p2sWCb1TnNq3as9OFoeVA9Q9vZUJxp5ed5sEn1YEKdqXALbCCrGwYQiRbgXigGF70aQh 92bAtzqS4qp6EWs2a36TML629SYWdN6f3MoXbq5fe/Q/KsRSoxV+R3oNIdVJUjeH7B7Q yotg== X-Received: by 10.14.119.196 with SMTP id n44mr34882eeh.116.1381825022925; Tue, 15 Oct 2013 01:17:02 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([46.211.77.102]) by mx.google.com with ESMTPSA id s3sm190612eeo.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 01:17:02 -0700 (PDT) Sender: Alexander Motin Message-ID: <525CF9FC.2000109@FreeBSD.org> Date: Tue, 15 Oct 2013 11:17:00 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: svn commit: r254846 - projects/camlock/sys/cddl/contrib/opensolaris/uts/common/fs/zfs References: <201308251121.r7PBLA3v033536@svn.freebsd.org> <521A06A2.7050807@FreeBSD.org> <201308261425.34743.jhb@freebsd.org> In-Reply-To: <201308261425.34743.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, Adrian Chadd , "src-committers@freebsd.org" X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:17:05 -0000 On 26.08.2013 21:25, John Baldwin wrote: > On Sunday, August 25, 2013 9:29:06 am Alexander Motin wrote: >> On 25.08.2013 15:48, Adrian Chadd wrote: >>> Surely there's a better way to check whether a thread can sleep besides >>> digging around in curthread->td_no_sleeping ? What about adding an >>> accessor macro along side THREAD_SLEEPING_OK and THREAD_NO_SLEEPING ? >> >> That sounds good to me. I was also surprised such macros are not there >> yet when found some code doing these checks just the same way as I did. > > It was never intended to be public, only as a debugging aid for assertions. :( > I had hoped that the calling code would know when it was in an ithread or not > and call different routines as needed (i.e. that the programmer would > intentionally think about the context they were in). Perhaps this is not > realistic? Are you really queueing new I/O from ithreads and/or timers? I've found potential case where it is not realistic. Requests are normally completed from the interrupt threads. Completion caller does know that it is impossible to sleep in that context. But it holds no locks, it is re-enterable, and so it allows direct completion. Request goes up the stack and at some point on the call chain this completion triggers another request to be sent down (may be even to some different device), but again directly. This new request sender knows nothing about interrupt context and the fact it can't sleep. Can you propose some other way to deal with such case other then using per-thread flag/counter? I could use separate per-thread counter, incremented during up call, but I don't see much benefits form it. If you don't want it to be system-wide accessible to not relax people too much, I could create GEOM-specific wrapper for it. -- Alexander Motin