Browse Prior Art Database

Method and Apparatus for System Level Bottleneck Detection and Reasoning Disclosure Number: IPCOM000181680D
Original Publication Date: 2009-Apr-09
Included in the Prior Art Database: 2009-Apr-09
Document File: 3 page(s) / 27K

Publishing Venue



More and more applications are developed as multi-threaded programs to make the most effective use of multi-core processors. It’s important to detect how these threads works and find out the reason of why those threads are blocked when CPU utilization is low. However, since there’re various resources being used, how to identify the system bottleneck more quickly and more precisely could be a problem. For solving the problem above, we propose a method and relevant apparatus for system level bottleneck detection. This method is self-contained and only two lightweight system instrumentations are needed. It’s particularly useful for reasoning the bottleneck of Java program when no indications can be found at JVM layer.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 3

Method and Apparatus for System Level Bottleneck Detection and Reasoning

1. Background: What is the problem solved by your invention? Describe known solutions to this problem (if any). What are the drawbacks of such known solutions, or why is an additional solution required? Cite any relevant technical documents or references. In the multi-core environment, multi-threaded applications become
increasingly main stream. For the programmers and deployers, it's important
to understand how these threads works and find out why those threads are
blocked when CPU utilization is low. One traditional solution is to use resource-specific monitoring. For
example, programmers or deployers usually use "top" tool to identify the
bottleneck on CPU. However, since each resource demands for a dedicated
tool, users have to combine the results from different performance tools to
identify the bottleneck. What's worse, there's no criteria to judge the
bottleneck based on these usage data. Another solution is to use stack analysis technologies, the main
defects about this approach are 1) Significant performance overhead, even
perturbation to the application behavior. 2) All stack calls will be
recorded, though not all of them are associated with thread stalling.

2. Summary of Invention: Briefly describe the core idea of your invention (saving the details for questions #3 below). Describe the advantage(s) of using your invention instead of the known solutions described above. This invention provides an efficient, light-weight and self-contained
method for system level bottleneck detection and reasoning. The main idea
is: because all the threads are blocked at the kernel space of operating
system through system call interface, we add two hookers at system call
function and context switch function. When a task (thread) is blocked and
invokes the context switch function, we'll try to get the system call
number and other parameters to identify which resource this thread
requested and failed to obtain.

Solution Outline

T h re a d 1 (ta sk 1 )

T h re a d 2 (ta sk 2 )

s ys ca ll

C o n te x t_ s w itc h

T 2

R e c o rd s ys ca ll ID


C h e c k th re a d s ta te

ta s k1

In te rru p tib le _ sle e p
U n in te rru p tib le _ s le e p

Advantages of the disclosure:

1. An efficient method for system level bottleneck detection, with
only two callbacks hooked into OS kernel. 2. An efficient method for reasoning the Java thread state changes
when no indications can be found at JVM layer. 3. Self-contained method without requiring other monitors or tools.

4. Lightweight system instrumentations without obvious performance
loss on target application.


Page 2 of 3

3. Descripti...