From owner-svn-src-projects@FreeBSD.ORG Mon Aug 26 19:03:48 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2F36B46F; Mon, 26 Aug 2013 19:03:48 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33BDD28A1; Mon, 26 Aug 2013 19:03:47 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id q16so1812111ead.35 for ; Mon, 26 Aug 2013 12:03:45 -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=yWtiCfCFtkmAaPYMGc1n+0lwtpmyqUEf73awCr6UO98=; b=G5+UJ43IeVJEk9Zg+l39DX2sg058zWBBIZKwShctw7QetsNCnCDjMp4g9POYvmgrue 6HX6QOzNAIue46aI9VzGmiqYSzzac5swcWCY3cvza7AvEBjKeuRK91xs1re+1yJ4w69F ZsmNDf+klH+NUC4BCdsC7dCrs7eQV2WMk/n/Y48penj4Z7G+3sGMxRLHhlitl3GdoAva vSJDPueXA3KY/b1kYhlK/d/E3DD5G/FV1NgBkWq5SSEAQkuMuZjX5XNy4IO8xx3yS+P2 u3j21lLuPXByBwxvFZ8rTfKQv9FLxpF2Bxls763KgrgDC5jHuudR/++Ikh3JlnaKud/x 6TXQ== X-Received: by 10.14.224.198 with SMTP id x46mr5672545eep.53.1377543825459; Mon, 26 Aug 2013 12:03:45 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([37.229.21.195]) by mx.google.com with ESMTPSA id b45sm23390706eef.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 12:03:44 -0700 (PDT) Sender: Alexander Motin Message-ID: <521BA68D.3070304@FreeBSD.org> Date: Mon, 26 Aug 2013 22:03:41 +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: Mon, 26 Aug 2013 19:03:48 -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 don't, but at least GEOM SCHED I think does it from callout context. I agree that caller code should usually know where it runs, and in such case it can control whether execute request directly or queue it. But queued requests are executed by GEOM threads, where sleeping is also denied for callee, i.e. not really much different. Same time zvol can benefit very much from ability to sleep in caller context, that I've implemented with this check. If not do it that way, I could replace that with check for whether we run explicitly from one of GEOM threads. That I think should be sufficient. -- Alexander Motin