| 1 |
I am the same problems with 2.6.35, now I downgrade to 2.6.34-r6, it is |
| 2 |
normal till now |
| 3 |
|
| 4 |
2010/8/23 Alan Warren <bluemoonshine@×××××.com> |
| 5 |
|
| 6 |
> Thanks Mark, I'll look into that config option, and try again with top |
| 7 |
> open. |
| 8 |
> |
| 9 |
> In this case I was doing a home backup to a 1TB WD Caviar black formatted |
| 10 |
> as ext3. |
| 11 |
> |
| 12 |
> I also have a raid0 with 2 other non-WD sata drives, and a single WD |
| 13 |
> velociraptor I can test |
| 14 |
> with. |
| 15 |
> |
| 16 |
> It also doesn't sound too far off that FF could be the culprit (mentioned |
| 17 |
> above), as I have it |
| 18 |
> open all the time, and so far it's been the first place I've noticed these |
| 19 |
> hiccups. That could |
| 20 |
> be coincidence though, as I've pretty much always got it open and these |
| 21 |
> hiccups are |
| 22 |
> system wide. |
| 23 |
> |
| 24 |
> |
| 25 |
> On Mon, Aug 23, 2010 at 10:03 AM, Mark Knecht <markknecht@×××××.com>wrote: |
| 26 |
> |
| 27 |
>> On Sun, Aug 22, 2010 at 12:01 PM, Alan Warren <bluemoonshine@×××××.com> |
| 28 |
>> wrote: |
| 29 |
>> > Hello, |
| 30 |
>> > |
| 31 |
>> > I am having some system performance issues with this kernel release. I |
| 32 |
>> have |
| 33 |
>> > a SMP machine (dual xeon nehalem 8 core / 16 threads) with 24gb non-ecc |
| 34 |
>> > memory. |
| 35 |
>> > |
| 36 |
>> > On occasion (seems random so far) my system feels like a Pentium II |
| 37 |
>> trying |
| 38 |
>> > to cope with Vista. For example, I was in the middle of tar'ing a |
| 39 |
>> semi-large |
| 40 |
>> > file and noticed all of my apps came to a crawl. Scrolling in firefox, |
| 41 |
>> > typing in the terminal, or trying to navigate in my file manager |
| 42 |
>> resulted in |
| 43 |
>> > breif "pauses" that came in waves. On one occasion my system froze |
| 44 |
>> > completely and I had to manually reset the machine. (that was with |
| 45 |
>> > 2.6.35-r1) |
| 46 |
>> > |
| 47 |
>> > I didn't activate anything "new" in this kernel release that I don't |
| 48 |
>> > normally activate. ie, no cpuidle driver |
| 49 |
>> > |
| 50 |
>> > Is there a proper venu for debugging such matters, or should I just wait |
| 51 |
>> for |
| 52 |
>> > this kernel to go prime-time? |
| 53 |
>> > |
| 54 |
>> > Thanks for your time, |
| 55 |
>> > Alan |
| 56 |
>> > |
| 57 |
>> |
| 58 |
>> Hi Alan, |
| 59 |
>> Sorry for the problems. I've seen them also in the recent past. In |
| 60 |
>> my case it was on new hardware so I couldn't say it was due to a |
| 61 |
>> specific kernel release. |
| 62 |
>> |
| 63 |
>> 1) What happens when you watch top while doing the tar? Do you by any |
| 64 |
>> chance see large wait times in top? (Hit '1' to watch all CPUs) If so |
| 65 |
>> the problem could well be how the kernel is dealing with writing data |
| 66 |
>> back to the hard drive. I had this problem with the WD Green drives. |
| 67 |
>> When I changed to WD RAID Edition drives (1/2 the storage for 30% more |
| 68 |
>> money) the problems disappeared. |
| 69 |
>> |
| 70 |
>> 2) If it's not the drive issue then there is a kernel option called (I |
| 71 |
>> think) RCU_CPU_STALL_DETECTION (or something like that. If you turn it |
| 72 |
>> on I may generate a trace of what's keeping a core busy to long. |
| 73 |
>> Mileage will vary. |
| 74 |
>> |
| 75 |
>> Good luck, |
| 76 |
>> Mark |
| 77 |
>> |
| 78 |
>> |
| 79 |
> |
Archives