Page alloc problems with 2.6.32-rc kernels
Missed the CC's
Good morning,
Quoted 4 lines
I have the server running with all with patches applied and it runs without any issues. Since adding patch5 seems to make a difference I will revert 1-4 and only apply patch 5 to see if it work too. I will report back as soon as I have news.
Current status of my tests here. With only patch 5 applied (the revert)
I am not able to reproduce the problem. Reading through the ml archives
I noticed that this revert is somewhat controversial since it seems to
fix other bugs. Is it possible that reverting those fixes just hide the bug I am seeing instead of fixing it?
Kind regards,
Michael
Adding a few more CCs.
Quoted 10 lines · Michael Guntsche
Quoted 4 lines
I have the server running with all with patches applied and it runs without any issues. Since adding patch5 seems to make a difference I will revert 1-4 and only apply patch 5 to see if it work too. I will report back as soon as I have news.
Current status of my tests here. With only patch 5 applied (the revert) I am not able to reproduce the problem. Reading through the ml archives I noticed that this revert is somewhat controversial since it seems to fix other bugs. Is it possible that reverting those fixes just hide the bug I am seeing instead of fixing it?
Thanks Michael. That means we now have two cases where reverting the congestion_wait() changes from .31-rc3 (8aa7e847d8 + 373c0a7ed3) makes a clear and significant difference.
I wonder if more effort could/should be made on this aspect.
Cheers,
FJP
Quoted 5 lines · Frans Pop
Thanks Michael. That means we now have two cases where reverting the
congestion_wait()changes from .31-rc3 (8aa7e847d8+373c0a7ed3) makes a clear and significant difference.I wonder if more effort could/should be made on this aspect.
Good morning Frans,
As a cross check I reverted the revert here and tried to reproduce the problem again. It is a lot harder to trigger for me now (I was not able to reproduce it yet). I did update my local git tree though, can you reproduce this problem on your side with current git?
Kind regards,
Michael
Quoted 10 lines · Michael Guntsche
Quoted 5 lines · Frans Pop
Thanks Michael. That means we now have two cases where reverting the
congestion_wait()changes from .31-rc3 (8aa7e847d8+373c0a7ed3) makes a clear and significant difference.I wonder if more effort could/should be made on this aspect.
As a cross check I reverted the revert here and tried to reproduce the problem again. It is a lot harder to trigger for me now (I was not able to reproduce it yet). I did update my local git tree though,
OK. Can you tell us a bit more about your setup:
- how much RAM does the system have?
- what's so special about mutt in your case that it triggers these errors?
- do you maybe have a huge mailbox, so mutt uses a lot of memory?
- does starting/use mutt cause swapping when you see the errors?
- do you use disk encryption at all?
- if you do, what is encrypted: the file system, swap, both?
Quoted 1 line
From your first mail it does look as if you had little free memory and that
swap was in use.
Quoted 1 line
can you reproduce this problem on your side with current git?
Yes I can, but my test case is somewhat special as it forces a huge amount of swapping. It does look as if your problem may also be related to swapping activity.
Cheers,
FJP
Quoted 2 lines · Frans Pop
OK. Can you tell us a bit more about your setup:
- how much RAM does the system have?
512MB
Quoted 3 lines
- what's so special about mutt in your case that it triggers these errors?
- do you maybe have a huge mailbox, so mutt uses a lot of memory?
- does starting/use mutt cause swapping when you see the errors?
Mutt is accessing a maildir directory with a several subdirectories directly. All of them are added as mailboxes so I can jump to unread mails. During startup and folder changing mutt is accessing all the mailboxes.
Quoted 3 lines
From your first mail it does look as if you had little free memory and that swap was in use.
I noticed that as well.
During the last days memory usage was not that high so maybe this is the reason why I did not see any errors. I will continue running latest git and see if a get the errors again when more memory is being used.
Kind regards,
Michael