From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 4 21:30:01 2013 Return-Path: Delivered-To: freebsd-scsi@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 6C004C61; Wed, 4 Sep 2013 21:30:01 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 304392742; Wed, 4 Sep 2013 21:30:00 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id D4DB958385; Wed, 4 Sep 2013 16:29:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id C7+Tce5PvWx0; Wed, 4 Sep 2013 16:29:59 -0500 (CDT) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id A953E58384; Wed, 4 Sep 2013 16:29:59 -0500 (CDT) Message-ID: <5227A657.4010701@freebsd.org> Date: Wed, 04 Sep 2013 16:29:59 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking References: <520D4ADB.50209@FreeBSD.org> <52273F90.7020303@freebsd.org> <201309041200.56024.jhb@freebsd.org> In-Reply-To: <201309041200.56024.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org, "freebsd-hackers@freebsd.org" , Alexander Motin , freebsd-current@freebsd.org, Outback Dingo , =?ISO-8859-1?Q?Olivier_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 21:30:01 -0000 On 09/04/13 11:00, John Baldwin wrote: > 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. > Ah, very well. That's weird. Should be fine for PPC, however. -Nathan