Hi, I have some good news: the problem seems to be solved (at least for me) since I updated to r195011 about 2 weeks ago. I think it may be related to the MSI fixes (and the drm module may have been the cause, even if not used?), but I might be wrong. After this update, the permanent slowdown issue disappeared, but I still had some slowdown on high CPU load (but it was back to normal soon after coming back to a low load). I then figured out that it was due to an overheat problem on my laptop, slowing down the wall machine in some way... I've cleaned it up (there was a 5mm wall of dust in the fan!), and no more overheat nor slowdown since then. I'm sorry I can't reproduce it anymore now. ;) And I hope Randall's problem is fixed as well. :) Thanks for your help anyway! Pierre Guinoiseau Attilio Rao wrote: > 2009/6/24 Randall Stewart <rrs_at_lakerest.net>: >> One thing I have noticed for a while.. and have not >> been able to track down.. >> >> If one runs >> >> /usr/src/tools/tools/syscall_timing/syscall_timing >> >> On a 7.2 kernel and compare it on the same machine to an 8.0 kernel >> you will see almost a 3x slow down in 8. > > So, as long as I think that for the pressing, next release, it is very > important to track such regressions down, I hope both Pierre and > Randall want to lend an hand. > > First thing, Randall, could you recompile your kernel with > HWPMC_HOOKS, device hwpmc, and do some pmcstat runs in order to see > where/how the slowdown happens? > For example you could check if the number of cache misses increases, or similar. > > Both could provide, instead, once the slowdown takes place, verbose > top, ps and possibly vmstat, just to be sure in case. > > If you are unable to reproduce the slowdown or give an hand, please let me know. > > Thanks, > Attilio > >
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC