From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 4 13:20:43 2013 Return-Path: Delivered-To: freebsd-hackers@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 DB979543; Wed, 4 Sep 2013 13:20:43 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63677232C; Wed, 4 Sep 2013 13:20:43 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id o17so336172oag.7 for ; Wed, 04 Sep 2013 06:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uHQmwWU2MeBmE/1UIl47yFWFen4/AkTbDSQbsQhd/98=; b=enzMJG+Q9dZrdLHyb1h7LtN5bwcG03+y9VX9vqViqefI8Xfn4TWYmYwfAcF+qlPajc aRSfaiptbvyhvaBXy13j6fU3S8qgkA1ZiASZo8QW9xy1vfyntiguHgwsrg1rVQwoWZg0 jB94flQsMzViMSro/7HDhKwJZLEZvUQQfS/9sYmYkhxI5jZGBXOa4BQKDzWES1QGbwpf Oizz1P9WubWSrm92QtGsBkWB+HM2QdrYZQ75nCe/9u5j22q8bnkt57oAlQVtK5DjVh3h jOLiw/gTkx0IcWI8U/NIR79vbuBXa3nQiFrHMZU7uPRKg/gaSpIggGd7i6mi5HduGSY6 /2AQ== MIME-Version: 1.0 X-Received: by 10.182.73.136 with SMTP id l8mr2102864obv.53.1378300842725; Wed, 04 Sep 2013 06:20:42 -0700 (PDT) Received: by 10.76.68.38 with HTTP; Wed, 4 Sep 2013 06:20:42 -0700 (PDT) In-Reply-To: <52272B6F.9060308@freebsd.org> References: <520D4ADB.50209@FreeBSD.org> <5224511D.4090503@FreeBSD.org> <20130903134251.GB43281@caravan.chchile.org> <5226DAB0.1060303@FreeBSD.org> <52272B6F.9060308@freebsd.org> Date: Wed, 4 Sep 2013 09:20:42 -0400 Message-ID: Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking From: Ryan Stone To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-geom@freebsd.org, "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-current@freebsd.org" , Outback Dingo , =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , FreeBSD SCSI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 13:20:44 -0000 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)