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). > -- Dan Hain Solaris Revenue Product Engineering (RPE) http://namefinder/NameFinder?nfquery=-s+88796 -------------------------------------------------------------- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --------------------------------------------------------------
