| To: | Andi Kleen <andi@xxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Very aggressive memory reclaim |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Tue, 29 Mar 2011 12:57:27 +1100 |
| Cc: | John Lepikhin <johnlepikhin@xxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-mm@xxxxxxxxx |
| In-reply-to: | <m2bp0u23wl.fsf@xxxxxxxxxxxxxx> |
| References: | <AANLkTinFqqmE+fTMTLVU-_CwPE+LQv7CpXSQ5+CdAKLK@xxxxxxxxxxxxxx> <20110328215344.GC3008@dastard> <m2bp0u23wl.fsf@xxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.20 (2009-06-14) |
On Mon, Mar 28, 2011 at 04:58:50PM -0700, Andi Kleen wrote: > Dave Chinner <david@xxxxxxxxxxxxx> writes: > > > > 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 capturing an event > > Often it's to get pages of a higher order. Just tracing alloc_pages > should tell you that. 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 more data than needed the first time around than have to do multiple round trips because a single trace point doesn't tell us the cause... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: XFS memory allocation deadlock in 2.6.38, Dave Chinner |
|---|---|
| Next by Date: | Deborah sent you yhe Post eCard!, Deborah |
| Previous by Thread: | Re: Very aggressive memory reclaim, Andi Kleen |
| Next by Thread: | Re: Very aggressive memory reclaim, John Lepikhin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |