From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 4 16:07:51 2013 Return-Path: Delivered-To: freebsd-scsi@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 2BC56248; Wed, 4 Sep 2013 16:07:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA3DA2E7C; Wed, 4 Sep 2013 16:07:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 99108B941; Wed, 4 Sep 2013 12:07:49 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking Date: Wed, 4 Sep 2013 12:00:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <520D4ADB.50209@FreeBSD.org> <52273F90.7020303@freebsd.org> In-Reply-To: <52273F90.7020303@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201309041200.56024.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Sep 2013 12:07:49 -0400 (EDT) Cc: freebsd-geom@freebsd.org, "freebsd-hackers@freebsd.org" , Alexander Motin , Nathan Whitehorn , Outback Dingo , Olivier =?iso-8859-1?q?Cochard-Labb=E9?= , FreeBSD SCSI X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 16:07:51 -0000 On Wednesday, September 04, 2013 10:11:28 am Nathan Whitehorn wrote: > On 09/04/13 08:20, Ryan Stone wrote: > > On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn wrote: > >> Could you describe what this macro is supposed to do so that we can do the > >> porting work? > >> -Nathan > > #define GET_STACK_USAGE(total, used) > > > > GET_STACK_USAGE sets the variable passed in total to the total amount > > of stack space available to the current thread. used is set to the > > amount of stack space currently used (this does not have to have > > byte-precision). Netgraph uses this to decide when to stop recursing > > and instead defer to a work queue (to prevent stack overflow). I > > presume that Alexander is using it in a similar way. It looks like > > the amd64 version could be ported to other architectures quite easily > > if you were to account for stacks that grow up and stacks that grow > > down: > > > > http://svnweb.freebsd.org/base/head/sys/amd64/include/proc.h?revision=233291&view=markup > > > > /* Get the current kernel thread stack usage. */ > > #define GET_STACK_USAGE(total, used) do { \ > > struct thread *td = curthread; \ > > (total) = td->td_kstack_pages * PAGE_SIZE; \ > > (used) = (char *)td->td_kstack + \ > > td->td_kstack_pages * PAGE_SIZE - \ > > (char *)&td; \ > > } while (0) > > _______________________________________________ > > 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" > > I think that should be MI for us anyway. I'm not aware of any > architectures FreeBSD supports with stacks that grow up. I'll give it a > test on PPC. ia64 has the double stack thingie where the register stack spills into a stack that grows up rather than down. Not sure how sparc64 window spills are handled either. -- John Baldwin