Version: (using Devel) OS: Linux Installed from: Compiled sources The processes plasma-desktop, krunner and kded4 will over relatively short periode of time consume a lot of memory and cpu. I've tryed to close everything visible (panels, widgets) so that the onely thing visible was the system-activity program (ctrl+esc) and then just waited - the computer becomes unresponsive when krunner and kded4 reaches about 60MB each - Plasma-desktop is no problem as long as every plasmoid and everything visible is removed but becomes the fastest growing memory and cpu consumer when these are started. The problem looks to be linked to certain hardware configurations because I have two laptops with the exact same fresh Kubuntu installation (9.04) and it's only one of them that has the problem - I tried several different installations all showing the same result on both machines I hope this report is helpful - it is my first...
Can you check the list of running processes on both laptops? Which hardware is different?
Also, what is your KDE4 version ? Thanks
Now i've tested both laptops with the same comebase, meaning that I've booted both systems with the same usb-stick - first the kubuntu 9.04 iso and then the Kubuntu 9.10 alfa-release 5 on another stick. That way anyone can test with the exact same code base. System 1: Acer Aspire 9410 (the machine with the problem) System 2: Compaq Presario CQ61 On both Kubuntu's system 1 had rising memory- and cpu comsumption and on both Kubuntu's system 2 was rock solid when looking at memory and cpu usage. In my test I let the laptops boot and stay untouched for half an hour and then I took a picture with my mobile phone because I couldn't even take a screen dump with the acer machine - it was dead ;o) The links underneath is to the photos. system 1 - Kubuntu 9.04 - www.nobill.dk/Billede023.jpg system 1 - Kubuntu 9.10 alfa 5 - www.nobill.dk/Billede024.jpg system 2 - Kubuntu 9.04 - www.nobill.dk/Billede027.jpg system 2 - Kubuntu 9.10 alfa 5 - www.nobill.dk/Billede028.jpg I hope this info is enough to illustrate the problem. By the way, in the first of the four tests the memory used by plasma is extremely high, this happened when I started ksnapshot to make a schreen dump the memory jumped about 300MB so it didn't crawl all the way in half an hour but this is then another problem not to be discussed here ;o) /Carsten
The extreme memory use case is instead test nr. 2 - sorry ;o)
I am also seeing plasma-desktop using a lot of CPU and memory. My video card is an 8600 GTS running 185.18.31 drivers.
Several of the workstations in our laboratories tend to restart X, the log files indicating that krunner was killed: kernel: [20915.715458] Out of memory: kill process 26321 (krunner) score 2367772 or a child I'm happy to provide more information and help track it down, any pointers where to start?
plasma-desktop problem confirmed on my system, but less severe: I have two plasma widgets: A folder view of my home directory, and the analog clock. The plasma-desktop memory usage grows to 200 MB over about one week. Dell Latitude D630 with NVidia Quadro NVS 135M OpenSUSE 11.1 with KDE Factory 4.3.1 Desktop compositing enabled
.I can see that the problem exists in Kubuntu 9.10 beta - There must be some kind of similarity to the affected systems - my guess is something that has to do with the graphics driver combined with plasma-desktop and Kded4 which causes the severe leaks Krunner also has leaks but not nearly as severe. Further more it must be something else than widgets on the plasma desktop because the problem is still there when there are no widgets - not even the panel. I think it's strange that this is not considered a critical bug in Kde - if restarting plasma-desktop once every 15 minutes is not critical - what is then critical? maybe very few system-configurations have this problem and therefor not considered critical? but the fact that my laptop has a very normal main stream hardware this ought to annoy a lot of people - or...? My laptop is as mentioned an Acer Aspire 9410AWSMi with an intel core solo T1350 cpu, an Intel 950 graphics system, DDR2 memory and other totaly normal hardware not worth mentioning but nothing thats not very ordinary (very boring ;o) The only thing i could imagine that could have something to do with the memory leak would be my 'Intel Graphics Media Accelerator 950' - does anybody have any overlapping hardware that could cause the problem. /Carsten (Denmark)
I have the exact same problem for over a year and a half now. I cannot use KDE 4 daily on my laptop, which is my main computer, and I have been using gnome for all this time just because the desktop becomes unusable after a while (10-20 minutes). Here is a screenshot of my system monitor : http://tinypic.com/r/255nhg2/4 I also have an Acer Aspire 5680 laptop, 2Gb RAM, Nvidia GeForce Go 7600.
Sorry, forgot to mention I'm currently using Ubuntu 9.04.
Maybe it's the way Acer combines the different hardware? I use Kde4 every day - I'm not exactly a Gnome-fan ;o) and I have learned to live with the memory consumption by shutting down plasma-desktop and kded4 after a while and restart plasma-desktop (the Alt+F2 program starter) This is optimal but works for me - hope you can use it ;o) /Carsten
YES YES YES :o) All of my cpu- and memory problems are totally solved in the new Kubuntu 9.10 RC1 Memory use ajusts up and down as it should and after the update from 9.10 beta 5 i've run for hours and everything words exactly as it should - it must be the upgrade to Kde-4.3.3 that did the magic - I hope this update works for all of you too. Have to go... to pop the champaigne - cheers mates ;o)
looking forward trying kubuntu 9.10 I have similar memory issues with plasma-desktop using both 9.04 and archlinux
The problem is NOT solved for me in 4.3.3. I use no plasma widgets, plain desktop. The plasma-desktop process starts at 39 mb and grows to 200 mb over about a week, then I restart it becase KDE starts to become unresponsive. Dell Latitude D630 with NVidia Quadro NVS 135M OpenSUSE 11.1 with KDE Factory 4.3.3 release 1 Desktop compositing enabled
Again: Please reopen, the issue is *not* fixed.
This bug is now reopened as the bug has reappeared - the affected processes is still plasma-desktop, kded, krunner and kmix - they all consume more and more memory and cpu. 2009/12/1 Gunnstein Lye <gunnstein.lye@gmail.com>: > https://bugs.kde.org/show_bug.cgi?id=206317 > > > > > > --- Comment #15 from Gunnstein Lye <gunnstein lye gmail com> 2009-12-01 13:22:32 --- > Again: Please reopen, the issue is *not* fixed. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are a voter for the bug. > You reported the bug. >
This is a messy one to identify/fix. It should probably be splitted into separate reports (one per product) to tracked them down easily... In any case, about kded4.. it is just a helper app to run several daemons. You can select which daemons to run at System Settings/Advanced tab/Service Manager. You could try to disable one by one, all the services, and check if that helps a bit.. May be you can find the guilty service.. (if the leak is service related) Plasma could have a different situation...
I also suffer from this problems, at least with plasma-desktop. I use KDE on my work computer, which I seldomly reboot, and plasma-desktop memory usage rises above the 100 MBs. mark in less than a week. I have this problem since starting using KDE SC 4.0 up to the current KDE SC 4.4.0 beta 2, in several Kubuntu releases. I'll be more than happy in offering any help I can to solve this problem. What testing procedure should I follow? What data can I provide?
*** This bug has been confirmed by popular vote. ***
Same problem on KDE 4.4 RC1 on Kubuntu Karmic: after ~20-30 hours of work I see that plasma-desktop process eats more that 200mb of memory. If I use xrestop and look at the plasma-desktop, it shows only 10-20 mb of usage. I can provide more info for debug this problem.
I can confirm that this still happens in KDE SC 4.4 RC 1. I've tried deleting plasma configuration files and using the default desktop with no additional widgets but it made no difference.
There is (if it wasn't fixed in last two weeks) a memory leak in plasma notifications which can be easily reproduced when Kopete shows online status change notifications (or any notification that hides automatically).
The issue seems solved for me after the upgrade from 4.3 to 4.4.2. Initial memory usage is up from about 39 to 64 MB, but it has stayed there for about a week. Dell Latitude D630 with NVidia Quadro NVS 135M OpenSUSE 11.1 with KDE Factory 4.4.2 Desktop compositing enabled
Now I have kde 4.4.2 and at 4 days of uptime, plasma eats about 100mb of memory: # ps aux | grep plasma USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND murz 4540 1.1 2.7 867800 102808 ? Sl May04 32:34 kdeinit4: plasma-desktop [kdeinit] # uptime 19:38:00 up 4 days, 18:14, 6 users, load average: 0.30, 0.39, 0.46 Resolution is 1920x1080-24, driver is ati opensource (not fglrx), composing is disabled. Is it normal?
Hey everybody ;) I just installed (from scratch) Kubuntu 10.04 LTS on my laptop and unfortunately I've discovered that the memory consumption issue has reappeared but this time it only affects kded4. The problem seamed to be totally solved in 9.10 but now kded4 consumes more than 120MB in just about 2 hours. Have anybody experienced the same behavior in the new 10.04 LTS or is it just me? /Carsten
I still have problems but with plasma-desktop (nearly 200 Mbs. of memory in just a day) in Kubuntu 10.04 LTS. However, I haven't reinstalled from scratch, I just upgraded it. I plan to install Kubuntu from scratch. I'll report back then.
I also have problem with plasma-desktop eating my notebook's memory. I use KDE SC 4.5.0 on a Gentoo x86_64 installation. I have noticed that when I close one notification in the notification plasmoid the plasma-desktop process eats more memory (1 to 2 MB for each notification closed). That is weird, closing the notification should release memory and not increase its usage.
Also experiencing the same as Carsten, kded4 gradually uses more RAM (right now at 391M, and the virtual size is 1G). HP laptop DV1588EA Kubuntu 10.10 KDE 4.6. The problem became apparent after the KDE4.6 update. Anyone else?
I'm getting this, too on a Dell Latitude XT with 2 gig of RAM running Kubuntu Natty with FOSS ATI drivers which has KDE 4.6.0. KDED4 ram usage creeps up about a third of a meg every second, which adds up really fast! I've had KDE 4.6.0 since it was first packaged for Natty (just before the official release date) and the problem only started for me a few days ago after doing an update. Memory usage continues to creep up even without any apps open (only plasmoids are two copies of the microblogging widget).
I can confirm this bug too. After 18 hours without restart kded4 uses 250mb of ram and keeps rising. Kubuntu Maverick KDE 4.6.1
*** Bug 269857 has been marked as a duplicate of this bug. ***
I'm not convinced that this is actually a duplicate of bug 269857. The symptoms seemt to be the same, but I used Kubuntu 9.10 with KDE 4.3.x before, - which should also be affected according to some of the comments here - and never experienced this behaviour before. It all started when I upgraded KDE, QT and its whole ecosystem to the versions contained in (K)Ubuntu Natty...
For the record: Kubuntu Natty AMD64 dev version, KDE 4.6.1, Qt 4.7.2 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22228 gunter 20 0 1701m 1.1g 7068 S 0 55.2 1:43.88 kded4
Unfortunately, situation does not seem to have improved in KDE 4.6.2. :-( I know the virtual memory size is not really significant per se, but look at it in relation to the swap usage... At the time this snapshot was copied from "top", kmail and kopete were the only running "real" KDE applications, in addition to several desktop plasmoids. (Analog clock, xeyes, comic viewer, music title viewer, notes, char selector and calendar.) As I wrote before, KDE 4.3 (running Kubuntu 9.10 Karmic Koala) used *much* less memory, it did much less swapping - with such few applications like kmail and kopete it was hardly swapping at all... Mem: 2047252k total, 1539664k used, 507588k free, 29480k buffers Swap: 1992024k total, 1382948k used, 609076k free, 769552k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2675 gunter 20 0 1311m 217m 10m S 0 10.9 1:14.81 kded4 18065 gunter 20 0 861m 112m 32m S 0 5.6 0:35.20 kmail 3036 gunter 20 0 761m 38m 7480 S 0 1.9 0:02.17 knotify4 3037 gunter 20 0 1133m 37m 13m S 3 1.9 12:07.61 plasma-desktop 18069 gunter 20 0 322m 29m 6628 S 0 1.5 0:00.66 kio_imap4 3217 gunter 20 0 720m 24m 13m S 0 1.2 0:27.00 kopete 3141 gunter 20 0 844m 24m 10m S 0 1.2 0:14.05 krunner
On my system it seems that kded4 memory leak appears when I use opensource ati driver. When I install fglrx, kded4 doesn't leak memory. The same leak occurs on both, Maverick KDE 4.6.2 and Natty KDE 4.6.2 installations. When I install fglrx, memory leak doesn't happen on both, Maverick and Natty. Is the a way to debug this leak?
Valgrind is the tool used to track memory leaks: http://valgrind.org/ I am starting to use it to track problems in my KDE programs. What I do is start a X session with only xterm opened, open a second xterm in background (xterm &), then in the first xterm I start kded4 through valgrind: valgrind -v --leak-check=full --log-file=kded4.log --malloc-fill=0xaa --free-fill=0xbb kded4 --dograb --nocrashhandler --nofork Notice the --nofork parameter, the first xterm will be blocked while valgrind is running, that is why I start a second xterm before valgrind. In the second xterm I launch the rest of the KDE session by calling startkde. Be warned that valgrind makes the program starts/run really slow, so be patient when running a program through valgrind. Be also warned that when kded4 crashes for whatever reason it is automatically started by kdeinit4 without valgrind and without the kcrash dialog. So from time to time check if valgrind is still running. Good luck.
The observation that kded4's memory consumption is related to the graphics driver / graphics configuration is rather interesting! Out of curiosity I started X using fbdev instead of the Intel graphics driver and kded4 seems to be behaving a lot better this way. However, there are quite a few differences between the Intel and the fbdev configuration, as fbdev does not provide any acceleration and DRI and does not seem to support multihead, so a) it's no option for "real" everyday usage and b) it's hard to tell which of the differences causes kded4 to consume different amounts of memory. At least the compositor is also enabled with fbdev, though it's not using OpenGL in this case, of course. My stats with fbdev after a few hours of usage: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19862 root 20 0 340m 223m 5856 S 9 11.2 8:36.00 Xorg 20588 gunter 20 0 733m 142m 18m S 0 7.1 0:12.81 kded4 25525 gunter 20 0 1254m 112m 38m S 8 5.7 2:43.03 amarok 20776 gunter 20 0 861m 105m 34m S 0 5.3 0:53.41 kmail 20614 gunter 20 0 907m 98m 32m S 6 4.9 3:05.12 plasma-desktop
I don't have spare time at the moment to debug kded4 leak with opensource ati driver. At the moment I am using fglrx. Uptime of my system is 1d 4h 20m and kded4 uses only 7mb of ram. Before I installed fglrx, kded4 leaked over 150 mb in 2 hours and kept rising! When I have spare time I will try to debug it.
Mh, I fear I rejoiced too soon... I'm still running with fbdev and memory is getting scarce again... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20588 gunter 20 0 1180m 509m 17m S 0 25.5 0:52.84 kded4 19862 root 20 0 339m 218m 4232 S 19 11.0 27:43.34 Xorg 20614 gunter 20 0 880m 96m 28m S 4 4.8 9:10.81 plasma-desktop 18204 gunter 20 0 613m 80m 36m S 12 4.0 0:27.81 konqueror 20700 gunter 20 0 914m 54m 29m S 0 2.7 0:31.27 krunner
(copied from bug 271934) If this is reproducible, please disable kded4 modules in "System Settings > Startup and Shutdown > Service Manager" to see which one is the culprit. Some modules cannot be disabled there. To disable such a module, remove its .desktop file from /usr/share/kde4/services/kded/, run kbuildsycoca4, and restart kded4. The information which module causes the leak helps fixing the issue.
It is absolutely reproducible, it happens always. The memory leak does need some time to show, however, so I'm not sure how long it'll take to get meaningful results... I'll try a "binary search" to narrow this down...
For kded4, one reporter said it might be caused by the KMixD module. Can anyone confirm by disabling only that? Mine is enabled, and doesn't cause leaks, but then again, it probably has to do with the Phonon backend (I still use xine), PulseAudio support etc.
One thing: I've used Kubuntu 11.04 since beta 1 with xine and then, after some issues, changed to gstreamer and discarded Pulseaudio as I hitted another issue changing Phonon backend in amarok.The leak has been there all the way since I got 11.04, so I *guess* it might not be about the Phonon backend and all that. I didn't address that variable carefully (because I just wanted sound to work properly) so I can't tell for sure. Hope this helps. On Tue, May 3, 2011 at 5:08 PM, Christoph Feck <christoph@maxiom.de> wrote: > https://bugs.kde.org/show_bug.cgi?id=206317 > > > > > > --- Comment #42 from Christoph Feck <christoph maxiom de> 2011-05-04 > 00:08:35 --- > For kded4, one reporter said it might be caused by the KMixD module. Can > anyone > confirm by disabling only that? Mine is enabled, and doesn't cause leaks, > but > then again, it probably has to do with the Phonon backend (I still use > xine), > PulseAudio support etc. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
I already read that report and kmixd was among the modules I re-enabled after disabling all I could for the first test. I currently narrowing it down, or so I hope, but kmixd does not seem to be the culprit on my system.
Hello people. I've narrowed it down to the *Power Management* process. Or at least I guess so. I disabled that service from system settings >> startup >> Service Manager. Stopped it and set it not to start at boot. Rebooted. Let the session started for about 11 hours. kded4 stayed in healthy 16,812k. Looks like we nailed it. alfabravo@alfabravoTiger:~$ uptime 00:47:23 up 15:13, 2 users, load average: 0.06, 0.13, 0.09 Process 2397 - kded4 SummaryThe process *kded4* (with pid 2397) is using approximately 12.3 MB of memory. It is using 8.7 MB privately, and a further 26.5 MB that is, or could be, shared with other programs. Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 3.6 MB. Adding that to the private usage, we get the above mentioned total memory footprint of 12.3 MB. My battery is really old and worn out so maybe I experience an explosive increase rate for this leak... but looks like this is it. On Wed, May 4, 2011 at 2:07 PM, Gunter Ohrner <kdebugs@customcdrom.de>wrote: > https://bugs.kde.org/show_bug.cgi?id=206317 > > > > > > --- Comment #44 from Gunter Ohrner <kdebugs CustomCDROM de> 2011-05-04 > 21:07:49 --- > I already read that report and kmixd was among the modules I re-enabled > after > disabling all I could for the first test. > > I currently narrowing it down, or so I hope, but kmixd does not seem to be > the > culprit on my system. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
Do you believe me if I say that the Power Management module was the only one of the "KDE Startup"-services I had not yet tested? Murphy at his best... This seems to be a good catch, while kded4's process size always stayed constant after a while in my tests before, it grew to 750 MB RSS / 1.5 GB VMS during the last few hours with only very few services enabled, among them the Power Management service. I'll do a final test fpr verification and let it run with all modules enabled but Power Management, but that's basically the same as I did the night before, when I could not observe any memory loss.
I did one more test https://bugs.kde.org/show_bug.cgi?id=271934#c15 Hope it helps. And... don't know where should I keep track of this, given the fact that one bug report depends on the other. Anyhow, I tested that KDE startup service first because I had similar problems with gnome's equivalent service (which does not overrule Murphy, of course).
I let KDE run during the day with all "Startup"-services enabled but "Power Management", and kded4 behaved sane and kept a constant RSS. :-) So from my POV there's definitely something fishy about the "Power Management" service. BTW, I'm also using a notebook, yet with a relatively well-functioning battery. However, the memory loss I'm observing does not seem as extreme as what Andres is seeing, so maybe it really has something to do with battery state changes or something...
Done the test on my machine (Kubuntu 11.04, KDE 4.6.3). It's defnitely the Power Management Service. RSS and VSIZE behave normally until the Power Management Service is enabled (see below at 8:28:59). My laptop also has a shot battery (reports 25% capacity) so that may also be a factor. Dave Time :: rss vsize 8:28:19 :: 15752 207416 8:28:21 :: 15752 207416 ... 8:28:53 :: 15752 207416 8:28:55 :: 15752 207416 8:28:57 :: 15752 207416 8:28:59 :: 16840 207804 8:29:01 :: 18640 217528 8:29:03 :: 18640 217528 8:29:05 :: 18640 217528 8:29:07 :: 18640 217528 8:29:09 :: 18640 217528 8:29:11 :: 18640 217528 8:29:13 :: 18640 217528 8:29:15 :: 18816 217528 8:29:17 :: 18816 217528 8:29:19 :: 18816 217528 8:29:22 :: 18816 217528 8:29:24 :: 18816 217528 8:29:26 :: 18816 217528 8:29:28 :: 18816 217528 8:29:30 :: 18816 217528 8:29:32 :: 19536 218164 8:29:34 :: 19536 218164
Yes, when Power Management is disabled there is no leak. I as well tested only on an old laptop battery with 0% capacity.
Same behavior with hp laptop laptop (1year old). The battery is not very old but the memory leak was reproducible: 840MB heap memory for kded4 last afternoon after 2-3 hours of operation. Let me know if you require additional info on the issue.
There is no link in KDE 4.6 on Arch Linux. Tested with both good and old and bad batteries. Works flawlessly.
(In reply to comment #52) > There is no link in KDE 4.6 on Arch Linux. Tested with both good and old and > bad batteries. Works flawlessly. So sorry, meant leak.
Created attachment 60997 [details] kinfocenter
Created attachment 60998 [details] kde4 process info memory usage
This bug also affected me. My laptop has 3 gb of RAM + 5 gb of SWAP. In a matter of 2 hrs all of that memory is exhausted. The heap region of the kde4 process grows continually until there's no more swap at which point the laptop freezes w/ non-stop disk access taking place. Disabling the power management service fixed it for me. Laptop details: HP G60 (amd turion dual-core RM-72) kubuntu 11.04 64-bits (natty) PS.: I attached 2 screenshots to this bug showing the details of my laptop and the kde4 process memory usage.
Will this bug ever be fixed??!! Memory leak issue with power management service is 2 months old...
Assigning the bug to the Powerdevil developer. Let's see what Dario can say about it.
I am closing this bug because it has been split for each process that leaks memory. - kded4 leak caused by power management is bug 271934 - kmix leak is bug 264089 - plasma-desktop leak caused by notifications was bug 239007 For other Plasma leaks, see https://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=leak&product=plasma or report a new Plasma bug. If you get a memory leak in kded4 when power management is NOT running, please report a new bug or add a comment here. For more information about kded4, see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/
OK, I can see that this bug is closed, and that the culprit is probably that little devil called Powerdevil. :-) Adding some notes here, anyway, because it might help track down the problem. I'm on an Acer Aspire desktop machine here, 8 GB RAM, 20 GB swap. CPU info for one of the 8 cores reported by cpuinfo below. (I'm mentioning this because the problem seems to affect many Acer Aspire machines with AMD CPUs.) The box runs openSuse 12.1 with a 3.1 kernel and KDE 4.7.2. I get the discussed problem only in this scenario: * More than 1 KDE session running. * Box has been suspended to RAM, then resumed. * In the active KDE session (after resume), everything looks normal. * Box becomes mostly unresponsive after like 10 minutes. * Looking at System Monitor or top reveals that knotify *in the inactive session* has eaten up all physical RAM, and is making the box start swapping. * Switching to the inactive KDE session makes the problem go away almost immediately (well, after the box recovered from its swapping frenzy, which can take up to 5 minutes). As discussed here, I disabled KDE power management, and expect this to make the problem go away. Since this is a desktop machine it's actually an acceptable workaround, not so much for laptop computers I would assume. So, at least for me, the problem seems related to suspend/resume, inactive KDE sessions, and AMD processors. Hope this will help make the issue easier to debug. Cheers, Stefan # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 1 model name : AMD FX(tm)-8100 Eight-Core Processor stepping : 2 cpu MHz : 2800.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core arat cpb npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bogomips : 5586.68 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate [9] ...