From Daniel.Hain@sun.com Fri Mar 21 18:24:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2M1OkZm003821 for ; Fri, 21 Mar 2008 18:24:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2M1Oipl010378 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 22 Mar 2008 01:24:45 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY300L07YL8ZQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 Mar 2008 19:24:44 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY300KR4YL8SZ10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 Mar 2008 19:24:44 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2M1OiXf020319 for ; Fri, 21 Mar 2008 18:24:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JY300J01YHXVG00@fe-sfbay-10.sun.com> (original mail from Daniel.Hain@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 Mar 2008 18:24:44 -0700 (PDT) Received: from Macintosh.local ([72.197.213.236]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JY300FS3YL78MB0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 Mar 2008 18:24:43 -0700 (PDT) Date: Fri, 21 Mar 2008 18:24:42 -0700 From: Dan Hain Subject: PSARC 2008/206 A new (k)mdb command ::stackinfo, kernel thread stack usage Sender: Daniel.Hain@sun.com To: PSARC-ext@sun.com Cc: Philippe.Jung@sun.com, Ken Tomlinson Message-id: <47E45FDA.9@sun.com> Organization: Solaris Revenue Product Engineering MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 5097 I am sponsoring this FastTrack for Philippe Jung. Requested binding is Patch, timeout 3/28/2008. - Dan Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: new mdb stackinfo command 1.2. Name of Document Author/Supplier: Philippe Jung 1.3. Date of This Document: 02/29/2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: 1.4.2. The ARC(s) you expect to review your project: PSARC 1.5. Email Aliases: 1.5.2. Responsible Engineer: Philippe.Jung@sun.com 1.5.4. Interest List: Ken.Tomlinson@sun.com Renaud.Manus@sun.com William.Roche@sun.com Chris.Beal@sun.com 2. Project Summary 2.1. Project Description: Context: Some Solaris layered drivers (3rd parties) like EMC, Veritas requests a change of Solaris default kernel stack size. This project adds a new mdb command that helps to answer the following question: "How close has this Solaris system be from a kernel stack overflow ?". This project introduces a new mdb command (::stackinfo) and a new kernel tunable (kmem_stackinfo). At kernel thread creation time, the kernel thread stack is filled with a specific pattern (instead of zero filled) if the kmem_stackinfo variable is set to non zero value. During the kernel thread execution, the kernel thread stack pattern is progressively overwritten. This feature takes in account hardware architecture (stack grows either to lower or larger addresses). A simple count from stack top until pattern is not found (or stack botom is reached) gives a high water mark value, the maximum kernel stack space used by a kernel thread This allows to compute the maximum usage (a high water mark) of kernel stack usage. This new mdb command (::stackinfo) can also display the 'dead' kernel threads that have exercised their kernel stack the most (a DTRACE Statically Defined Tracing probe is also provided for this). Example: /etc/system: set kmem_stackinfo=0x1 > ::stackinfo THREAD STACK SIZE CUR MAX CMD/LWPID 000003000ec76a00 000002a10049a000 5ae0 3% 44% svc.startd/8 svc.startd/8 is currently at 3% of its kernel stack, but has already used up to 44% of its kernel stack. 2.2. Risks and Assumptions: None. 3. Business Summary 3.1. Problem Area: Helps answering Solaris developers/system admins the following question: "How close has this Solaris system be from a kernel stack overflow ?". 3.2. Market/Requester: Any Solaris kernel developer (layered drivers), any Solaris system administrator. 3.3. Business Justification: 3.4. Competitive Analysis: N/A. 3.5. Opportunity Window/Exposure: N/A. 3.6. How will you know when you are done?: The project is already available. Project and code review has been performed by following people: Ken.Tomlinson@sun.com Renaud.Manus@sun.com William.Roche@sun.com Chris.Beal@sun.com 4. Technical Description: 4.1. Details: file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf 4.2. Bug/RFE Number(s): 6626918 A new (k)mdb command ::stackinfo, kernel thread stack usage 4.3. In Scope: N/A. 4.4. Out of Scope: N/A. 4.5. Interfaces: A new tunable in /etc/system, like slab allocator debug kmem_flags. set kmem_stackinfo = 0x1 A new (k)mdb command: > ::help stackinfo NAME stackinfo - display kthread_t stack usage SYNOPSIS [ addr ] ::stackinfo DESCRIPTION -a show also TS_FREE kthreads -h print history (dead kthreads) ATTRIBUTES Target: kvm Module: genunix Interface Stability: Unstable A new Dtrace probe: sdt:genunix:thread_log_stk_usage_free:stack-usage 4.6. Doc Impact: None. 4.7. Admin/Config Impact: None. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. 4.10. Packaging & Delivery: None (no new package or existing package modification). 4.11. Security Impact: None. 4.12. Dependencies: None. 5. Reference Documents: file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html 6. Resources and Schedule: 6.1. Projected Availability: 2 weeks 6.2. Cost of Effort: development: 2 man/week (done) QE: QA: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: 6.4.7. Target RTI Date/Release: 6.4.8. Target Code Design Review Date: 6.5. ARC review type: // Standard // SelfReview 6.6. ARC Exposure: open 6.6.1. Rationale: Part of OpenSolaris 7. Prototype Availability: 7.1. Prototype Availability: file:///net/tb3.uk/tank/u/pjung/onnv_stack/webrev/index.html /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf 7.2. Prototype Cost: None (Prototype done). From gww@eng.sun.com Sat Mar 22 10:53:13 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2MHrCIh013203 for ; Sat, 22 Mar 2008 10:53:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2MHr7ED003772 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 23 Mar 2008 01:53:12 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY500C038CKMQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 22 Mar 2008 11:53:08 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY5001JR8CKC740@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 22 Mar 2008 11:53:08 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2MHr771057452; Sat, 22 Mar 2008 10:53:07 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m2MIrOmi009464; Sat, 22 Mar 2008 10:53:24 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2MIrOYU009463; Sat, 22 Mar 2008 10:53:24 -0800 (PST) Date: Sat, 22 Mar 2008 10:53:24 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2008/206 A new (k)mdb command ::stackinfo, kernel thread stack usage To: PSARC-ext@sun.com, Daniel.Hain@sun.com Cc: Philippe.Jung@sun.com, Ken.Tomlinson@sun.com Message-id: <200803221853.m2MIrOYU009463@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1174 > I am sponsoring this FastTrack for Philippe Jung. > Requested binding is Patch, timeout 3/28/2008. Some nits. > 4.5. Interfaces: > > A new tunable in /etc/system, like slab allocator debug kmem_flags. > > set kmem_stackinfo = 0x1 What's the Interface Stability of this? Must it be hex? The description says non-zero? Where/how is its presence documented? > ATTRIBUTES > > Target: kvm > Module: genunix > Interface Stability: Unstable ^^^^^^^^ Not a valid Interface Stability. See http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ > 5. Reference Documents: > > file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html Issues directly with this case's materials: This is an OpenSolaris ARC case. Internal to Sun files cannot be references. If this is important to the case, it must be part of the case material. P.S. file URLs suck[tm] even in house, they take forever to mount cross internal domains. Plus they do not work from browsers on systems unless the system is also automounting from in house. That is it won't work from my laptop since I don't run an NFS client or automount. Gary.. From Philippe.Jung@Sun.COM Sat Mar 22 13:16:23 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2MKGN1W018758 for ; Sat, 22 Mar 2008 13:16:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2MKGNNE013853 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 22 Mar 2008 13:16:23 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY500101EZBHM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 22 Mar 2008 14:16:23 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY5001H2EZ9C8B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 22 Mar 2008 14:16:22 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2MKGLCe000138 for ; Sat, 22 Mar 2008 20:16:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JY500J01ER57100@fe-emea-10.sun.com> (original mail from Philippe.Jung@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 22 Mar 2008 20:16:21 +0000 (GMT) Received: from [192.168.0.10] ([82.225.48.207]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JY500915EZ844C0@fe-emea-10.sun.com>; Sat, 22 Mar 2008 20:16:20 +0000 (GMT) Date: Sat, 22 Mar 2008 21:17:04 +0100 From: philippe jung Sun Subject: Re: PSARC 2008/206 A new (k)mdb command ::stackinfo, kernel thread stack usage In-reply-to: <200803221853.m2MIrOYU009463@marduk.eng.sun.com> Sender: Philippe.Jung@Sun.COM To: Gary Winiger Cc: PSARC-ext@Sun.COM, Daniel.Hain@Sun.COM, Ken.Tomlinson@Sun.COM Message-id: <47E56940.70204@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZyyY0CgujZEeyT2owLH6/Q)" X-PMX-Version: 5.4.1.325704 References: <200803221853.m2MIrOYU009463@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 4348 This is a multi-part message in MIME format. --Boundary_(ID_ZyyY0CgujZEeyT2owLH6/Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Gary Winiger a écrit : >> I am sponsoring this FastTrack for Philippe Jung. >> Requested binding is Patch, timeout 3/28/2008. >> > > Some nits. > > >> 4.5. Interfaces: >> >> A new tunable in /etc/system, like slab allocator debug kmem_flags. >> >> set kmem_stackinfo = 0x1 >> > > What's the Interface Stability of this? Must it be hex? The > description says non-zero? Where/how is its presence documented? > > >> ATTRIBUTES >> >> Target: kvm >> Module: genunix >> Interface Stability: Unstable >> > ^^^^^^^^ > Not a valid Interface Stability. See > http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ > > >> 5. Reference Documents: >> >> file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html >> > > Issues directly with this case's materials: > > This is an OpenSolaris ARC case. Internal to Sun files cannot > be references. If this is important to the case, it must be part > of the case material. > P.S. file URLs suck[tm] even in house, they take forever to mount > cross internal domains. Plus they do not work from browsers on > systems unless the system is also automounting from in house. > That is it won't work from my laptop since I don't run an NFS > client or automount. > The public link for 'reference documents' section: http://bugs.opensolaris.org/view_bug.do;jsessionid=9c224491a1dd49262ac72ebb1835?bug_id=6626918 > Gary.. > --Boundary_(ID_ZyyY0CgujZEeyT2owLH6/Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger a écrit : 
I am sponsoring this FastTrack for Philippe Jung. 
Requested binding is Patch, timeout 3/28/2008.
    

	Some nits.

  
    4.5. Interfaces:

	A new tunable in /etc/system, like slab allocator debug kmem_flags.

	set kmem_stackinfo = 0x1
    

	What's the Interface Stability of this?  Must it be hex?  The
	description says non-zero?  Where/how is its presence documented?

  
	ATTRIBUTES
	
	  Target: kvm
	  Module: genunix
	  Interface Stability: Unstable
    
			       ^^^^^^^^
	Not a valid Interface Stability.  See
http://opensolaris.org/os/community/arc/policies/interface-taxonomy/

  
5. Reference Documents:

	file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html
    

	Issues directly with this case's materials:

	This is an OpenSolaris ARC case.  Internal to Sun files cannot
	be references.  If this is important to the case, it must be part
	of the case material.
	P.S. file URLs suck[tm] even in house, they take forever to mount
	cross internal domains.  Plus they do not work from browsers on
	systems unless the system is also automounting from in house.
	That is it won't work from my laptop since I don't run an NFS
	client or automount.
The public link for 'reference documents' section:

http://bugs.opensolaris.org/view_bug.do;jsessionid=9c224491a1dd49262ac72ebb1835?bug_id=6626918
Gary..

--Boundary_(ID_ZyyY0CgujZEeyT2owLH6/Q)-- From Alan.Hargreaves@sun.com Mon Mar 24 17:49:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2P0nD6d022084 for ; Mon, 24 Mar 2008 17:49:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2P0n1F5015687 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 25 Mar 2008 00:49:12 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY900B0RGXVHW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 Mar 2008 17:49:07 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY900MAQGXTW3F0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 Mar 2008 17:49:06 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2P0nEIu007012 for ; Tue, 25 Mar 2008 00:49:14 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JY900701GTU8F00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 25 Mar 2008 08:49:02 +0800 (SGT) Received: from [129.158.12.60] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JY900JLXGXNE7D2@mail-apac.sun.com>; Tue, 25 Mar 2008 08:49:01 +0800 (SGT) Date: Tue, 25 Mar 2008 11:49:02 +1100 From: Alan Hargreaves Subject: Re: PSARC 2008/206 A new (k)mdb command ::stackinfo, kernel thread stack usage In-reply-to: <47E56940.70204@sun.com> Sender: Alan.Hargreaves@sun.com To: philippe jung Sun Cc: Gary Winiger , PSARC-ext@sun.com, Daniel.Hain@sun.com, Ken.Tomlinson@sun.com Message-id: <47E84BFE.1040205@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200803221853.m2MIrOYU009463@marduk.eng.sun.com> <47E56940.70204@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080129) Status: RO Content-Length: 614 philippe jung Sun wrote: > Gary Winiger a écrit : >>> I am sponsoring this FastTrack for Philippe Jung. >>> Requested binding is Patch, timeout 3/28/2008. >> >>> 4.5. Interfaces: >>> >>> A new tunable in /etc/system, like slab allocator debug kmem_flags. >>> >>> set kmem_stackinfo = 0x1 If this interface is to be supported, it is important that it be well documented. I *hope* there are plans to get this into the Tunable Parameters guide. Regards, alan. -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Support Centre Sun Microsystems From Philippe.Jung@sun.com Thu Mar 27 00:49:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2R7ncBn005375 for ; Thu, 27 Mar 2008 00:49:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2R7nQ1S022503 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 27 Mar 2008 07:49:34 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYD00903PQLHS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 00:49:33 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYD00DQIPQK7K60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 00:49:33 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2R7nVEr024864 for ; Thu, 27 Mar 2008 07:49:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYD00K01PPYGU00@fe-emea-09.sun.com> (original mail from Philippe.Jung@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 27 Mar 2008 07:49:31 +0000 (GMT) Received: from [129.157.210.8] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYD00686PQJCM40@fe-emea-09.sun.com>; Thu, 27 Mar 2008 07:49:31 +0000 (GMT) Date: Thu, 27 Mar 2008 08:49:31 +0100 From: Philippe Jung Subject: Re: PSARC 2008/206 A new (k)mdb command ::stackinfo, kernel thread stack usage In-reply-to: <200803221853.m2MIrOYU009463@marduk.eng.sun.com> Sender: Philippe.Jung@sun.com To: Gary Winiger , Alan.Hargreaves@sun.com Cc: psarc-ext@sun.com, Daniel.Hain@sun.com, Ken.Tomlinson@sun.com Reply-to: Philippe.Jung@sun.com Message-id: <47EB518B.9070609@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hHzkU/vbZv4JXwWBBJWQlw)" X-PMX-Version: 5.4.1.325704 References: <200803221853.m2MIrOYU009463@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 6227 This is a multi-part message in MIME format. --Boundary_(ID_hHzkU/vbZv4JXwWBBJWQlw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: >> 4.5. Interfaces: >> >> A new tunable in /etc/system, like slab allocator debug kmem_flags. >> >> set kmem_stackinfo = 0x1 >> > > What's the Interface Stability of this? Must it be hex? The > description says non-zero? 4.5. Interfaces: A new tunable in /etc/system, kmem_stackinfo, an unsigned integer, default value is 0. (0: feature off, !=0: feature on) > Where/how is its presence documented? > > From Alan.Hargreaves@sun.com: "If this interface is to be supported, > it is important that it be well documented. I *hope* there are plans > to get this into the Tunable Parameters guide." > 4.6. Doc Impact Solaris Modular Debugger Guide Solaris Tunable Parameters Reference Manual >> ATTRIBUTES >> >> Target: kvm >> Module: genunix >> Interface Stability: Unstable >> > ^^^^^^^^ > Not a valid Interface Stability. See > http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ > ATTRIBUTES Target: kvm Module: genunix Interface Stability: Committed > >> 5. Reference Documents: >> >> file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html >> > > Issues directly with this case's materials: > > This is an OpenSolaris ARC case. Internal to Sun files cannot > be references. If this is important to the case, it must be part > of the case material. > P.S. file URLs suck[tm] even in house, they take forever to mount > cross internal domains. Plus they do not work from browsers on > systems unless the system is also automounting from in house. > That is it won't work from my laptop since I don't run an NFS > client or automount. > > Gary.. > 5. Reference Documents: http://bugs.opensolaris.org/view_bug.do?bug_id=6626918 -- Philippe JUNG Sun microsystems GEG http://gec.sun.com/ 180, Avenue de l'Europe mailto:philippe.jung@sun.com ZIRST de Montbonnot tel: +33 4 76 18 80 58 38334 Saint Ismier Cedex --Boundary_(ID_hHzkU/vbZv4JXwWBBJWQlw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote:
    4.5. Interfaces:

	A new tunable in /etc/system, like slab allocator debug kmem_flags.

	set kmem_stackinfo = 0x1
    

	What's the Interface Stability of this?  Must it be hex?  The
	description says non-zero?
4.5. Interfaces:

    A new tunable in /etc/system, kmem_stackinfo,
    an unsigned integer, default value is 0.
    (0: feature off, !=0: feature on) 
 Where/how is its presence documented?
  
From Alan.Hargreaves@sun.com: "If this interface is to be supported,
it is important that it be well  documented. I *hope* there are plans
to get this into the Tunable Parameters guide."
4.6. Doc Impact

        Solaris Modular Debugger Guide
        Solaris Tunable Parameters Reference Manual

  

    
	ATTRIBUTES
	
	  Target: kvm
	  Module: genunix
	  Interface Stability: Unstable
    

  

  
			       ^^^^^^^^
	Not a valid Interface Stability.  See
http://opensolaris.org/os/community/arc/policies/interface-taxonomy/
  




	ATTRIBUTES


	  Target: kvm
	  Module: genunix
	  Interface Stability: Committed




  
  

  

    
5. Reference Documents:

	file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html
    

  

  

	Issues directly with this case's materials:

	This is an OpenSolaris ARC case.  Internal to Sun files cannot
	be references.  If this is important to the case, it must be part
	of the case material.
	P.S. file URLs suck[tm] even in house, they take forever to mount
	cross internal domains.  Plus they do not work from browsers on
	systems unless the system is also automounting from in house.
	That is it won't work from my laptop since I don't run an NFS
	client or automount.

Gary..
  



5. Reference Documents:



        http://bugs.opensolaris.org/view_bug.do?bug_id=6626918




-- 
Philippe JUNG                          Sun microsystems GEG http://gec.sun.com/
180, Avenue de l'Europe                mailto:philippe.jung@sun.com
ZIRST de Montbonnot                    tel: +33 4 76 18 80 58
38334 Saint Ismier Cedex





--Boundary_(ID_hHzkU/vbZv4JXwWBBJWQlw)--

From gww@eng.sun.com Tue Apr  1 15:57:06 2008
Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m31Mv60K003483
	for ; Tue, 1 Apr 2008 15:57:06 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m31Mv6bH027224
	for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 1 Apr 2008 15:57:06 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JYO00B015355800@brm-avmta-1.central.sun.com> for psarc-ext@sun.com
 (ORCPT psarc-ext@sun.com); Tue, 01 Apr 2008 16:57:05 -0600 (MDT)
Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JYO000M8534P360@brm-avmta-1.central.sun.com> for
 psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue,
 01 Apr 2008 16:57:05 -0600 (MDT)
Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224])
	by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2)
 with ESMTP id m31Mv2Il027060; Tue, 01 Apr 2008 15:57:02 -0700 (PDT)
Received: from marduk.eng.sun.com (localhost [127.0.0.1])
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m31NvZ9q022953; Tue,
 01 Apr 2008 15:57:35 -0800 (PST)
Received: (from gww@localhost)
	by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m31NvZVr022952; Tue,
 01 Apr 2008 15:57:35 -0800 (PST)
Date: Tue, 01 Apr 2008 15:57:35 -0800 (PST)
From: Gary Winiger 
Subject: Re: PSARC 2008/206  A new (k)mdb command ::stackinfo,
 kernel thread stack usage
To: Alan.Hargreaves@sun.com, Philippe.Jung@sun.com, gww@eng.sun.com
Cc: Daniel.Hain@sun.com, Ken.Tomlinson@sun.com, psarc-ext@sun.com
Message-id: <200804012357.m31NvZVr022952@marduk.eng.sun.com>
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 1184

> >> 	A new tunable in /etc/system, like slab allocator debug kmem_flags.
> >>
> >> 	set kmem_stackinfo = 0x1
> >>     
> >
> > 	What's the Interface Stability of this?  Must it be hex?  The
> > 	description says non-zero? 
> 4.5. Interfaces:
> 
>     A new tunable in /etc/system, kmem_stackinfo,
>     an unsigned integer, default value is 0.
>     (0: feature off, !=0: feature on)
> >  Where/how is its presence documented?
> >   
> > From Alan.Hargreaves@sun.com: "If this interface is to be supported,
> > it is important that it be well  documented. I *hope* there are plans
> > to get this into the Tunable Parameters guide."
> >   
> 4.6. Doc Impact
> 
>         Solaris Modular Debugger Guide
>         Solaris Tunable Parameters Reference Manual

	So if I read this correctly, the /etc/system variable will
	only be documented in the docs.sun.com docs and not the man
	pages.  But there's a Committed ::stackinfo (k)mdb command
	that will be documented in the man page(s) and ::help, but
	it's activation will not be?

	I'm not concerned with the content of the case, but how
	admins/users/developers/debuggers will put the pieces
	together to activate and use it.

Gary..

From Philippe.Jung@sun.com Wed Apr  2 00:54:30 2008
Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m327sUQH017825
	for ; Wed, 2 Apr 2008 00:54:30 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m327sTeh021083
	for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Apr 2008 00:54:30 -0700 (PDT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JYO0060TTYQXV00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com
 (ORCPT psarc-ext@sun.com); Wed, 02 Apr 2008 01:54:26 -0600 (MDT)
Received: from gmp-eb-inf-2.sun.com ([192.18.6.24])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JYO00L1VTYORN60@brm-avmta-1.central.sun.com> for
 psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed,
 02 Apr 2008 01:54:25 -0600 (MDT)
Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10])
	by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m327sOos020988	for
 ; Wed, 02 Apr 2008 07:54:24 +0000 (GMT)
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JYO00E01TM9VY00@fe-emea-09.sun.com>
 (original mail from Philippe.Jung@Sun.COM)
 for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed,
 02 Apr 2008 08:54:24 +0100 (BST)
Received: from [129.157.210.6] by fe-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JYO008KRTYNWD50@fe-emea-09.sun.com>; Wed,
 02 Apr 2008 08:54:24 +0100 (BST)
Date: Wed, 02 Apr 2008 09:54:23 +0200
From: Philippe Jung 
Subject: Re: PSARC 2008/206  A new (k)mdb command ::stackinfo,
 kernel thread stack usage
In-reply-to: <200804012357.m31NvZVr022952@marduk.eng.sun.com>
Sender: Philippe.Jung@sun.com
To: Gary Winiger 
Cc: Alan.Hargreaves@sun.com, Daniel.Hain@sun.com, Ken.Tomlinson@sun.com,
        psarc-ext@sun.com
Reply-to: Philippe.Jung@sun.com
Message-id: <47F33BAF.9050002@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804012357.m31NvZVr022952@marduk.eng.sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070802)
Status: RO
Content-Length: 1691

Gary Winiger wrote:
>>>> 	A new tunable in /etc/system, like slab allocator debug kmem_flags.
>>>>
>>>> 	set kmem_stackinfo = 0x1
>>>>     
>>>>         
>>> 	What's the Interface Stability of this?  Must it be hex?  The
>>> 	description says non-zero? 
>>>       
>> 4.5. Interfaces:
>>
>>     A new tunable in /etc/system, kmem_stackinfo,
>>     an unsigned integer, default value is 0.
>>     (0: feature off, !=0: feature on)
>>     
>>>  Where/how is its presence documented?
>>>   
>>> From Alan.Hargreaves@sun.com: "If this interface is to be supported,
>>> it is important that it be well  documented. I *hope* there are plans
>>> to get this into the Tunable Parameters guide."
>>>   
>>>       
>> 4.6. Doc Impact
>>
>>         Solaris Modular Debugger Guide
>>         Solaris Tunable Parameters Reference Manual
>>     
>
> 	So if I read this correctly, the /etc/system variable will
> 	only be documented in the docs.sun.com docs and not the man
> 	pages.  But there's a Committed ::stackinfo (k)mdb command
> 	that will be documented in the man page(s) and ::help, but
> 	it's activation will not be?
>
> 	I'm not concerned with the content of the case, but how
> 	admins/users/developers/debuggers will put the pieces
> 	together to activate and use it.
>
> Gary..
>   
Understood.
The ::help stackinfo display will be modified to explain
also the kmem_stackinfo tunable, and describe more the feature,
like in section "4.1. Details".

-- 
Philippe JUNG                          Sun microsystems GEG http://gec.sun.com/
180, Avenue de l'Europe                mailto:philippe.jung@sun.com
ZIRST de Montbonnot                    tel: +33 4 76 18 80 58
38334 Saint Ismier Cedex


From carlsonj@phorcys.east.sun.com Wed Apr  2 04:13:35 2008
Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m32BDYYS023856
	for ; Wed, 2 Apr 2008 04:13:34 -0700 (PDT)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m32BDRnE023429;
	Wed, 2 Apr 2008 19:13:29 +0800 (SGT)
Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by
 brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JYP00L0136F0H00@brm-avmta-1.central.sun.com>; Wed,
 02 Apr 2008 05:13:27 -0600 (MDT)
Received: from phorcys.east.sun.com ([129.148.174.143])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JYP00IEG36E4930@brm-avmta-1.central.sun.com>; Wed,
 02 Apr 2008 05:13:27 -0600 (MDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m32BDPF5010111; Wed,
 02 Apr 2008 07:13:25 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m32BDP1T010108; Wed,
 02 Apr 2008 07:13:25 -0400 (EDT)
Date: Wed, 02 Apr 2008 07:13:25 -0400
From: James Carlson 
Subject: Re: PSARC 2008/206  A new (k)mdb command ::stackinfo,
	kernel thread stack usage
In-reply-to: <200804012357.m31NvZVr022952@marduk.eng.sun.com>
To: Gary Winiger 
Cc: Alan.Hargreaves@sun.com, Philippe.Jung@sun.com, Daniel.Hain@sun.com,
        Ken.Tomlinson@sun.com, psarc-ext@sun.com
Message-id: <18419.27221.460335.402345@gargle.gargle.HOWL>
MIME-version: 1.0
X-Mailer: VM 7.01 under Emacs 21.3.1
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <200804012357.m31NvZVr022952@marduk.eng.sun.com>
Status: RO
Content-Length: 709

Gary Winiger writes:
> 	So if I read this correctly, the /etc/system variable will
> 	only be documented in the docs.sun.com docs and not the man
> 	pages.  But there's a Committed ::stackinfo (k)mdb command
> 	that will be documented in the man page(s) and ::help, but
> 	it's activation will not be?

It's really no different from the existing (kernel) ::findleaks, which
is useless unless you've set the kmem_flags /etc/system variable.  It
follows existing precedent in this area.

-- 
James Carlson, Solaris Networking              
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From Daniel.Hain@sun.com Wed Apr  2 11:24:45 2008
Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m32IOiQ2013382
	for ; Wed, 2 Apr 2008 11:24:44 -0700 (PDT)
Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m32IOgmd018438
	for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Apr 2008 19:24:43 +0100 (BST)
Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by
 nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JYP0000PN56P200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com
 (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 11:24:42 -0700 (PDT)
Received: from sca-es-mail-2.sun.com ([192.18.43.133])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JYP00MSVN55ZD60@nwk-avmta-2.sfbay.sun.com> for
 PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed,
 02 Apr 2008 11:24:41 -0700 (PDT)
Received: from fe-sfbay-09.sun.com ([192.18.43.129])
	by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m32IOf3H024406	for
 ; Wed, 02 Apr 2008 11:24:41 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JYP00F01MXCN000@fe-sfbay-09.sun.com>
 (original mail from Daniel.Hain@Sun.COM)
 for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed,
 02 Apr 2008 11:24:41 -0700 (PDT)
Received: from dhcp-usan09-88-152.West.Sun.COM ([129.153.88.152])
 by fe-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JYP00M90N51NS00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com
 (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 11:24:38 -0700 (PDT)
Date: Wed, 02 Apr 2008 11:24:35 -0700
From: Dan Hain 
Subject: Re: PSARC 2008/206  A new (k)mdb command ::stackinfo,
 kernel thread stack usage
In-reply-to: <47E45FDA.9@sun.com>
Sender: Daniel.Hain@sun.com
To: Dan Hain 
Cc: PSARC-ext@sun.com, Philippe.Jung@sun.com,
        Ken Tomlinson 
Message-id: <47F3CF63.8030906@sun.com>
Organization: Solaris Revenue Product Engineering
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <47E45FDA.9@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 6348

This case was approved during today's PSARC meeting.

Dan



Dan Hain wrote:
> I am sponsoring this FastTrack for Philippe Jung. Requested binding is 
> Patch, timeout 3/28/2008.
>
> - Dan
>
>
> Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information 
> is Copyright 2007 Sun Microsystems
> 1. Introduction
>   1.1. Project/Component Working Name: new mdb stackinfo command
>
>   1.2. Name of Document Author/Supplier:
>     Philippe Jung
>
>   1.3. Date of This Document:
>     02/29/2008
>
>   1.4. Name of Major Document Customer(s)/Consumer(s):
>        1.4.1. The Community you expect to review your project:
>        1.4.2. The ARC(s) you expect to review your project:
>         PSARC
>
>   1.5. Email Aliases:
>        1.5.2. Responsible Engineer: Philippe.Jung@sun.com
>        1.5.4. Interest List:
>         Ken.Tomlinson@sun.com
>         Renaud.Manus@sun.com
>         William.Roche@sun.com
>         Chris.Beal@sun.com
>
> 2. Project Summary
>   2.1. Project Description:
>
>     Context: Some Solaris layered drivers (3rd parties) like EMC, Veritas
>     requests a change of Solaris default kernel stack size. This project
>     adds a new mdb command that helps to answer the following question:
>     "How close has this Solaris system be from a kernel stack overflow 
> ?".
>     This project introduces a new mdb command (::stackinfo) and a new 
> kernel
>     tunable (kmem_stackinfo).     At kernel thread creation time, the 
> kernel thread stack is filled with
>     a specific pattern (instead of zero filled) if the kmem_stackinfo 
> variable
>     is set to non zero value. During the kernel thread execution, the 
> kernel
>     thread stack pattern is progressively overwritten.
>     This feature takes in account hardware architecture (stack grows 
> either to
>        lower or larger addresses). A simple count from stack top until 
> pattern is
>     not found (or stack botom is reached) gives a high water mark 
> value, the
>     maximum kernel stack space used by a kernel thread
>     This allows to compute the maximum usage (a high water mark) of 
> kernel stack
>     usage. This new mdb command (::stackinfo) can also display the 
> 'dead' kernel
>     threads that have exercised their kernel stack the most (a DTRACE 
> Statically
>     Defined Tracing probe is also provided  for this).
>     Example:
>     /etc/system: set kmem_stackinfo=0x1
>     > ::stackinfo
>               THREAD            STACK   SIZE  CUR  MAX CMD/LWPID
>     000003000ec76a00 000002a10049a000   5ae0   3%  44% svc.startd/8
>
>     svc.startd/8 is currently at 3% of its kernel stack, but has already
>     used up to 44% of its kernel stack.
>
>
>   2.2. Risks and Assumptions:
>
>     None.
>     
> 3. Business Summary
>   3.1. Problem Area:
>
>     Helps answering Solaris developers/system admins the following 
> question:
>     "How close has this Solaris system be from a kernel stack overflow 
> ?".
>
>   3.2. Market/Requester:
>
>     Any Solaris kernel developer (layered drivers), any Solaris system
>     administrator.
>
>   3.3. Business Justification:
>
>
>   3.4. Competitive Analysis:
>
>     N/A.
>
>   3.5. Opportunity Window/Exposure:
>
>     N/A.
>
>   3.6. How will you know when you are done?:
>
>     The project is already available. Project and code review has been
>     performed by following people:
>         Ken.Tomlinson@sun.com Renaud.Manus@sun.com William.Roche@sun.com
>         Chris.Beal@sun.com
>
> 4. Technical Description:
>    4.1. Details:
>
>     file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html
>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw
>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf
>    4.2. Bug/RFE Number(s):
>
>     6626918 A new (k)mdb command ::stackinfo, kernel thread stack usage
>
>    4.3. In Scope:
>
>     N/A.
>
>    4.4. Out of Scope:
>
>     N/A.
>
>    4.5. Interfaces:
>
>     A new tunable in /etc/system, like slab allocator debug kmem_flags.
>
>     set kmem_stackinfo = 0x1
>
>     A new (k)mdb command:
>     > ::help stackinfo
>
>     NAME
>       stackinfo - display kthread_t stack usage
>     
>     SYNOPSIS
>       [ addr ] ::stackinfo     
>     DESCRIPTION
>          -a show also TS_FREE kthreads
>          -h print history (dead kthreads)
>     
>     ATTRIBUTES
>     
>       Target: kvm
>       Module: genunix
>       Interface Stability: Unstable
>
>     A new Dtrace probe:
>     sdt:genunix:thread_log_stk_usage_free:stack-usage
>
>    4.6. Doc Impact:
>
>     None.
>
>    4.7. Admin/Config Impact:
>
>     None.
>
>    4.8. HA Impact:
>
>     None.
>
>    4.9. I18N/L10N Impact:
>
>     None.
>
>    4.10. Packaging & Delivery:
>
>     None (no new package or existing package modification).
>
>    4.11. Security Impact:
>
>     None.
>
>    4.12. Dependencies:
>
>     None.
>
> 5. Reference Documents:
>
>     file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html
>
> 6. Resources and Schedule:
>   6.1. Projected Availability:
>
>     2 weeks
>
>   6.2. Cost of Effort:
>
>     development: 2 man/week (done)
>     QE:
>     QA:
>
>   6.4. Product Approval Committee requested information:
>        6.4.1. Consolidation or Component Name:
>        6.4.7. Target RTI Date/Release:
>        6.4.8. Target Code Design Review Date:
>
>   6.5. ARC review type:
>                //   Standard
>                //   SelfReview
>   6.6. ARC Exposure: open
>       6.6.1. Rationale: Part of OpenSolaris
>
> 7. Prototype Availability:
>   7.1. Prototype Availability:
>
>     file:///net/tb3.uk/tank/u/pjung/onnv_stack/webrev/index.html
>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw
>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf
>   7.2. Prototype Cost:
>
>     None (Prototype done).
>


-- 
Dan Hain 
Solaris Revenue Product Engineering (RPE)


From Philippe.Jung@sun.com Thu Apr  3 00:04:14 2008
Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3374Dix004847
	for ; Thu, 3 Apr 2008 00:04:13 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m33745Ux002880
	for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 3 Apr 2008 15:04:12 +0800 (SGT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0JYQ00M0DMAXEO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com
 (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 00:04:09 -0700 (PDT)
Received: from gmp-eb-inf-2.sun.com ([192.18.6.24])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JYQ00137MAWUFC0@nwk-avmta-1.sfbay.Sun.COM> for
 PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu,
 03 Apr 2008 00:04:09 -0700 (PDT)
Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12])
	by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33748sb001778	for
 ; Thu, 03 Apr 2008 07:04:08 +0000 (GMT)
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JYQ00001LZJDJ00@fe-emea-09.sun.com>
 (original mail from Philippe.Jung@Sun.COM)
 for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu,
 03 Apr 2008 08:04:08 +0100 (BST)
Received: from [129.157.210.6] by fe-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JYQ006EOMA57E70@fe-emea-09.sun.com> for PSARC-ext@sun.com
 (ORCPT PSARC-ext@sun.com); Thu, 03 Apr 2008 08:03:41 +0100 (BST)
Date: Thu, 03 Apr 2008 09:03:41 +0200
From: Philippe Jung 
Subject: Re: PSARC 2008/206  A new (k)mdb command ::stackinfo,
 kernel thread stack usage
In-reply-to: <47F3CF63.8030906@sun.com>
Sender: Philippe.Jung@sun.com
To: Dan Hain 
Cc: PSARC-ext@sun.com, Ken Tomlinson 
Reply-to: Philippe.Jung@sun.com
Message-id: <47F4814D.4020309@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
References: <47E45FDA.9@sun.com> <47F3CF63.8030906@sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070802)
Status: RO
Content-Length: 6277

Hi, Daniel

Thanks for the sponsoring.
> This case was approved during today's PSARC meeting.
>
> Dan
>
>
>
> Dan Hain wrote:
>> I am sponsoring this FastTrack for Philippe Jung. Requested binding 
>> is Patch, timeout 3/28/2008.
>>
>> - Dan
>>
>>
>> Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information 
>> is Copyright 2007 Sun Microsystems
>> 1. Introduction
>>   1.1. Project/Component Working Name: new mdb stackinfo command
>>
>>   1.2. Name of Document Author/Supplier:
>>     Philippe Jung
>>
>>   1.3. Date of This Document:
>>     02/29/2008
>>
>>   1.4. Name of Major Document Customer(s)/Consumer(s):
>>        1.4.1. The Community you expect to review your project:
>>        1.4.2. The ARC(s) you expect to review your project:
>>         PSARC
>>
>>   1.5. Email Aliases:
>>        1.5.2. Responsible Engineer: Philippe.Jung@sun.com
>>        1.5.4. Interest List:
>>         Ken.Tomlinson@sun.com
>>         Renaud.Manus@sun.com
>>         William.Roche@sun.com
>>         Chris.Beal@sun.com
>>
>> 2. Project Summary
>>   2.1. Project Description:
>>
>>     Context: Some Solaris layered drivers (3rd parties) like EMC, 
>> Veritas
>>     requests a change of Solaris default kernel stack size. This project
>>     adds a new mdb command that helps to answer the following question:
>>     "How close has this Solaris system be from a kernel stack 
>> overflow ?".
>>     This project introduces a new mdb command (::stackinfo) and a new 
>> kernel
>>     tunable (kmem_stackinfo).     At kernel thread creation time, the 
>> kernel thread stack is filled with
>>     a specific pattern (instead of zero filled) if the kmem_stackinfo 
>> variable
>>     is set to non zero value. During the kernel thread execution, the 
>> kernel
>>     thread stack pattern is progressively overwritten.
>>     This feature takes in account hardware architecture (stack grows 
>> either to
>>        lower or larger addresses). A simple count from stack top 
>> until pattern is
>>     not found (or stack botom is reached) gives a high water mark 
>> value, the
>>     maximum kernel stack space used by a kernel thread
>>     This allows to compute the maximum usage (a high water mark) of 
>> kernel stack
>>     usage. This new mdb command (::stackinfo) can also display the 
>> 'dead' kernel
>>     threads that have exercised their kernel stack the most (a DTRACE 
>> Statically
>>     Defined Tracing probe is also provided  for this).
>>     Example:
>>     /etc/system: set kmem_stackinfo=0x1
>>     > ::stackinfo
>>               THREAD            STACK   SIZE  CUR  MAX CMD/LWPID
>>     000003000ec76a00 000002a10049a000   5ae0   3%  44% svc.startd/8
>>
>>     svc.startd/8 is currently at 3% of its kernel stack, but has already
>>     used up to 44% of its kernel stack.
>>
>>
>>   2.2. Risks and Assumptions:
>>
>>     None.
>>     3. Business Summary
>>   3.1. Problem Area:
>>
>>     Helps answering Solaris developers/system admins the following 
>> question:
>>     "How close has this Solaris system be from a kernel stack 
>> overflow ?".
>>
>>   3.2. Market/Requester:
>>
>>     Any Solaris kernel developer (layered drivers), any Solaris system
>>     administrator.
>>
>>   3.3. Business Justification:
>>
>>
>>   3.4. Competitive Analysis:
>>
>>     N/A.
>>
>>   3.5. Opportunity Window/Exposure:
>>
>>     N/A.
>>
>>   3.6. How will you know when you are done?:
>>
>>     The project is already available. Project and code review has been
>>     performed by following people:
>>         Ken.Tomlinson@sun.com Renaud.Manus@sun.com William.Roche@sun.com
>>         Chris.Beal@sun.com
>>
>> 4. Technical Description:
>>    4.1. Details:
>>
>>     file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html
>>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw
>>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf
>>    4.2. Bug/RFE Number(s):
>>
>>     6626918 A new (k)mdb command ::stackinfo, kernel thread stack usage
>>
>>    4.3. In Scope:
>>
>>     N/A.
>>
>>    4.4. Out of Scope:
>>
>>     N/A.
>>
>>    4.5. Interfaces:
>>
>>     A new tunable in /etc/system, like slab allocator debug kmem_flags.
>>
>>     set kmem_stackinfo = 0x1
>>
>>     A new (k)mdb command:
>>     > ::help stackinfo
>>
>>     NAME
>>       stackinfo - display kthread_t stack usage
>>         SYNOPSIS
>>       [ addr ] ::stackinfo         DESCRIPTION
>>          -a show also TS_FREE kthreads
>>          -h print history (dead kthreads)
>>         ATTRIBUTES
>>           Target: kvm
>>       Module: genunix
>>       Interface Stability: Unstable
>>
>>     A new Dtrace probe:
>>     sdt:genunix:thread_log_stk_usage_free:stack-usage
>>
>>    4.6. Doc Impact:
>>
>>     None.
>>
>>    4.7. Admin/Config Impact:
>>
>>     None.
>>
>>    4.8. HA Impact:
>>
>>     None.
>>
>>    4.9. I18N/L10N Impact:
>>
>>     None.
>>
>>    4.10. Packaging & Delivery:
>>
>>     None (no new package or existing package modification).
>>
>>    4.11. Security Impact:
>>
>>     None.
>>
>>    4.12. Dependencies:
>>
>>     None.
>>
>> 5. Reference Documents:
>>
>>     file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html
>>
>> 6. Resources and Schedule:
>>   6.1. Projected Availability:
>>
>>     2 weeks
>>
>>   6.2. Cost of Effort:
>>
>>     development: 2 man/week (done)
>>     QE:
>>     QA:
>>
>>   6.4. Product Approval Committee requested information:
>>        6.4.1. Consolidation or Component Name:
>>        6.4.7. Target RTI Date/Release:
>>        6.4.8. Target Code Design Review Date:
>>
>>   6.5. ARC review type:
>>                //   Standard
>>                //   SelfReview
>>   6.6. ARC Exposure: open
>>       6.6.1. Rationale: Part of OpenSolaris
>>
>> 7. Prototype Availability:
>>   7.1. Prototype Availability:
>>
>>     file:///net/tb3.uk/tank/u/pjung/onnv_stack/webrev/index.html
>>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw
>>     /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf
>>   7.2. Prototype Cost:
>>
>>     None (Prototype done).
>>
>
>


-- 
Philippe JUNG                          Sun microsystems GEG http://gec.sun.com/
180, Avenue de l'Europe                mailto:philippe.jung@sun.com
ZIRST de Montbonnot                    tel: +33 4 76 18 80 58
38334 Saint Ismier Cedex