Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Very\s+aggressive\s+memory\s+reclaim\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Very\s+aggressive\s+memory\s+reclaim\s*$/: 9 ]

Total 9 documents matching your query.

1. Re: Very aggressive memory reclaim (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 29 Mar 2011 08:53:44 +1100; [cc xfs and mm lists] First it would be useful to determine why the VM is reclaiming so much memory. If it is somewhat predictable when the excessive reclaim is going to happen, it might be worth cap; /archives/xfs/2011-03/msg00328.html (9,221 bytes)
2. Re: Very aggressive memory reclaim (score: 1): Author: Minchan Kim <minchan.kim@xxxxxxxxx>; Date: Tue, 29 Mar 2011 07:52:14 +0900; Recently, We had a similar issue. http://www.spinics.net/lists/linux-mm/msg12243.html But it seems to not merge. I don't know why since I didn't follow up the thread. Maybe Cced guys can help you. Is; /archives/xfs/2011-03/msg00330.html (10,881 bytes)
3. Re: Very aggressive memory reclaim (score: 1): Author: Andi Kleen <andi@xxxxxxxxxxxxxx>; Date: Mon, 28 Mar 2011 16:58:50 -0700; Often it's to get pages of a higher order. Just tracing alloc_pages should tell you that. There are a few other cases (like memory failure handling), but they're more obscure. -Andi -- ak@xxxxxxxxxxx; /archives/xfs/2011-03/msg00331.html (8,413 bytes)
4. Re: Very aggressive memory reclaim (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 29 Mar 2011 12:57:27 +1100; Yes, the kmem/mm_page_alloc tracepoint gives us that. But in case that is not the cause, grabbing all the trace points I suggested is more likely to indicate where the problem is. I'd prefer to get m; /archives/xfs/2011-03/msg00334.html (8,778 bytes)
5. Re: Very aggressive memory reclaim (score: 1): Author: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>; Date: Tue, 29 Mar 2011 11:55:03 +0900 (JST); If my remember is correct, 2.6.38 is included Mel's anti agressive reclaim patch. And original report seems to be using 2.6.37.x. John, can you try 2.6.38?; /archives/xfs/2011-03/msg00337.html (8,461 bytes)
6. Re: Very aggressive memory reclaim (score: 1): Author: John Lepikhin <johnlepikhin@xxxxxxxxx>; Date: Tue, 29 Mar 2011 11:22:57 +0400; 2011/3/29 Minchan Kim <minchan.kim@xxxxxxxxx>: See attachment. Right now I have no zoneinfo for crisis time, but I can catch it if required. Attachment: zoneinfo Description: Binary data Attachment:; /archives/xfs/2011-03/msg00339.html (10,280 bytes)
7. Re: Very aggressive memory reclaim (score: 1): Author: John Lepikhin <johnlepikhin@xxxxxxxxx>; Date: Tue, 29 Mar 2011 11:26:00 +0400; 2011/3/29 Dave Chinner <david@xxxxxxxxxxxxx>: Do you mean I must add some debug to mm functions? I don't know any other way to catch such events.; /archives/xfs/2011-03/msg00340.html (9,882 bytes)
8. Re: Very aggressive memory reclaim (score: 1): Author: John Lepikhin <johnlepikhin@xxxxxxxxx>; Date: Tue, 29 Mar 2011 11:33:32 +0400; 2011/3/29 KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>: I'll ask my boss about it. Unfortunately we found opposite issue with memory management + XFS (100M of inodes) on 2.6.38: some objects in x; /archives/xfs/2011-03/msg00341.html (10,146 bytes)
9. Re: Very aggressive memory reclaim (score: 1): Author: Avi Kivity <avi@xxxxxxxxxx>; Date: Tue, 29 Mar 2011 10:59:33 +0200; Do you mean I must add some debug to mm functions? I don't know any other way to catch such events. Download and build trace-cmd (git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git),; /archives/xfs/2011-03/msg00342.html (9,845 bytes)

Current List: 1 - 9
Page: [1]