PSARC 2008/206 A new (k)mdb command ::stackinfo, kernel thread stack usage
Philippe Jung
Philippe.Jung at sun.com
Thu Apr 3 00:03:41 PDT 2008
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 at sun.com
>> 1.5.4. Interest List:
>> Ken.Tomlinson at sun.com
>> Renaud.Manus at sun.com
>> William.Roche at sun.com
>> Chris.Beal at 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 at sun.com Renaud.Manus at sun.com William.Roche at sun.com
>> Chris.Beal at 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 at sun.com
ZIRST de Montbonnot tel: +33 4 76 18 80 58
38334 Saint Ismier Cedex
More information about the opensolaris-arc
mailing list