Bug 1111099 - high system cpu utilization in intel_idle [NEEDINFO]
Summary: high system cpu utilization in intel_idle
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-19 08:55 UTC by Markus Stockhausen
Modified: 2014-12-10 14:57 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-12-10 14:57:14 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)
utilization graph (22.10 KB, image/png)
2014-06-19 08:56 UTC, Markus Stockhausen
no flags Details

Description Markus Stockhausen 2014-06-19 08:55:44 UTC
Description of problem:

Intel Core i7 system with 6 VMs has high system utilization in intel_idle driver. 

Version-Release number of selected component (if applicable):

Fedora 20
Linux kernel 3.14.7-200.fc20.x86_64
Intel Core i7 920
Motherboard Supermicro - Chipset Intel X58

How reproducible:

persistent

Steps to Reproduce:
1. start system 
2. start VMs
3. watch system utilization (vmstat)

Actual results:

system consumes 10% of CPU in sytem tasks

Expected results:

system should use less resources

Additional info:

A vmstat:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 14361496 171508 664704  0    0    0    68 7107 17688  6 10 84  0
 0  0      0 14364152 171508 664704  0    0    0     0 6488 14111  5 11 84  0
 1  0      0 14366256 171508 664708  0    0    0     0 6791 14200  6 12 82  0
 1  0      0 14367736 171508 664708  0    0    0    32 6624 15677  6 10 84  0
 0  0      0 14366164 171508 664708  0    0    0     0 6258 14805  6  9 85  0
 0  0      0 14367912 171508 664708  0    0    0     0 6330 14187  6 12 82  0
 1  0      0 14370316 171508 664732  0    0    0     0 6793 15457  6 10 84  0

The system has ksm/qemu running so we divide the system calls further into those additional processes. For the math we use:

System time of ksm: take system times from /proc/ksm-pid/stat
System time of qemu: sum system times from /proc/qemu-pids/stat
System time rest: System time /proc/stat - qemu/system - ksm/system

The collected data is attached in an rrd graph. As you can see half of the 11% system times go to ksm/qemu. The rest cannot be identified.

A perf record -a -g gives as top "consumer" very high utilization in intel_idle driver

-   9,16%          swapper  [kernel.kallsyms]             [k] intel_idle                                    
   - intel_idle                                                                                       
      - 99,89% cpuidle_enter_state                                                                    
           cpuidle_idle_call                                                                          
           arch_cpu_idle                                                                              
         - cpu_startup_entry                                                                          
              68,72% start_secondary                                                                  
            - 31,28% rest_init                                                                        
                 start_kernel                                                                         
                 x86_64_start_reservations                                                            
                 x86_64_start_kernel                                                                  
-   5,82%             ksmd  [kernel.kallsyms]             [k] memcmp                                  
   - memcmp                                                                                           
      - 98,94% memcmp_pages                                                                           
         - 96,81% ksm_scan_thread                                                                     
              kthread                                                                                 
              ret_from_fork                                                                           
         + 3,19% try_to_merge_with_ksm_page                                                           
      + 1,06% ksm_scan_thread       

A second server with a similar load does not expose that behaviour. Is that desired? Where should I start to look?

Comment 1 Markus Stockhausen 2014-06-19 08:56:52 UTC
Created attachment 910305 [details]
utilization graph

Comment 2 Justin M. Forbes 2014-11-13 15:55:41 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

Comment 3 Justin M. Forbes 2014-12-10 14:57:14 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.