Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751246AbaJAJ05 (ORCPT ); Wed, 1 Oct 2014 05:26:57 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:35992 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751047AbaJAJ0z (ORCPT ); Wed, 1 Oct 2014 05:26:55 -0400 Message-ID: <542BC8D6.7060306@canonical.com> Date: Wed, 01 Oct 2014 11:26:46 +0200 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Peter Hurley , Alex Deucher CC: Mel Gorman , Shaohua Li , Rik van Riel , Thomas Hellstrom , Hugh Dickens , Linux kernel , "dri-devel@lists.freedesktop.org" , linux-mm , Andrew Morton , Linus Torvalds , Ingo Molnar Subject: Re: page allocator bug in 3.16? References: <54246506.50401@hurleysoftware.com> <542484BF.7080908@hurleysoftware.com> In-Reply-To: <542484BF.7080908@hurleysoftware.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 25-09-14 om 23:10 schreef Peter Hurley: > On 09/25/2014 04:33 PM, Alex Deucher wrote: >> On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley wrote: >>> After several days uptime with a 3.16 kernel (generally running >>> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple >>> desktop workspaces) I've been seeing some really extreme slowdowns. >>> >>> Mostly the slowdowns are associated with gpu-related tasks, like >>> opening new emacs windows, switching workspaces, laughing at internet >>> gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue >>> it right away -- 3.15 is the first time suspend has worked reliably. >>> >>> This week I started looking into what the slowdown was and discovered >>> it's happening during dma allocation through swiotlb (the cpus can do >>> intel iommu but I don't use it because it's not the default for most users). >>> >>> I'm still working on a bisection but each step takes 8+ hours to >>> validate and even then I'm no longer sure I still have the 'bad' >>> commit in the bisection. [edit: yup, I started over] >>> >>> I just discovered a smattering of these in my logs and only on 3.16-rc+ kernels: >>> Sep 25 07:57:59 thor kernel: [28786.001300] alloc_contig_range test_pages_isolated(2bf560, 2bf562) failed >>> >>> This dual-Xeon box has 10GB and sysrq Show Memory isn't showing heavy >>> fragmentation [1]. >>> >>> Besides Mel's page allocator changes in 3.16, another suspect commit is: >>> >>> commit b13b1d2d8692b437203de7a404c6b809d2cc4d99 >>> Author: Shaohua Li >>> Date: Tue Apr 8 15:58:09 2014 +0800 >>> >>> x86/mm: In the PTE swapout page reclaim case clear the accessed bit instead of flushing the TLB >>> >>> Specifically, this statement: >>> >>> It could cause incorrect page aging and the (mistaken) reclaim of >>> hot pages, but the chance of that should be relatively low. >>> >>> I'm wondering if this could cause worse-case behavior with TTM? I'm >>> testing a revert of this on mainline 3.16-final now, with no results yet. >>> >>> Thoughts? >> You may also be seeing this: >> https://lkml.org/lkml/2014/8/8/445 > Thanks Alex. That is indeed the problem. > > Still reading the email thread to find out where the patches > are that fix this. Although it doesn't make much sense to me > that nouveau sets up a 1GB GART and then uses TTM which is > trying to shove all the DMA through a 16MB CMA window > (which turns out to be the base Ubuntu config). > > Regards, > Peter Hurley > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1362261 CMA's already disabled on x86 in most recent ubuntu kernels. :-) ~Maarten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/