From owner-svn-src-head@freebsd.org Mon Nov 23 06:02:23 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2775CA35FB5; Mon, 23 Nov 2015 06:02:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E49E319CB; Mon, 23 Nov 2015 06:02:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcph11 with SMTP id ph11so45006935igc.1; Sun, 22 Nov 2015 22:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5BSSHIxBFmUIguFJBughHXfSs378QTluyA/Yv0josPk=; b=lPays9Ec3UYbTD/mVUS0PVfrNf6cn1RZfz1H6fVKMNkjdUiVVlUS8ljzEZJMwrjcZc 7amKbjLemKL3zb9ZypTVsbKl2aX1kfhHeVZyFaB1jEZOOoxcD+BZXTgj4/m+drXtkKnX 27qGk9pdn+rCrqAmEwDU/vtpnbOl8xAL5ExXB/REC2AKqU/CMc4n2a2MWkDg4c/m0B2b jaVYVGTtTioP4HWeAwui9wuBY48XauuQF8L+vjcjLlEjJK84g/yMIFkzVYqiFVvHgdy0 M2UTGJ9ZBLSSamrseUy9GBBAFph7U22zoociCT0MT/4a904sb2lN/QKH5Ker1HOrrXLv XeYg== MIME-Version: 1.0 X-Received: by 10.50.73.228 with SMTP id o4mr10866516igv.37.1448258542204; Sun, 22 Nov 2015 22:02:22 -0800 (PST) Received: by 10.36.217.196 with HTTP; Sun, 22 Nov 2015 22:02:22 -0800 (PST) In-Reply-To: <1448254044.1398.22.camel@freebsd.org> References: <201511211955.tALJt18a052565@repo.freebsd.org> <20151123032253.GA2084@raichu> <1448254044.1398.22.camel@freebsd.org> Date: Sun, 22 Nov 2015 22:02:22 -0800 Message-ID: Subject: Re: svn commit: r291142 - in head/sys: arm/arm arm64/arm64 mips/mips powerpc/powerpc x86/x86 From: Adrian Chadd To: Ian Lepore Cc: Mark Johnston , Svatopluk Kraus , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 06:02:23 -0000 On 22 November 2015 at 20:47, Ian Lepore wrote: > On Sun, 2015-11-22 at 19:22 -0800, Mark Johnston wrote: >> On Sat, Nov 21, 2015 at 07:55:01PM +0000, Svatopluk Kraus wrote: >> > Author: skra >> > Date: Sat Nov 21 19:55:01 2015 >> > New Revision: 291142 >> > URL: https://svnweb.freebsd.org/changeset/base/291142 >> > >> > Log: >> > Fix BUS_DMA_MIN_ALLOC_COMP flag logic. When bus_dmamap_t map is >> > being >> > created for bus_dma_tag_t tag, bounce pages should be allocated >> > only if needed. >> > >> > Before the fix, they were allocated always if >> > BUS_DMA_COULD_BOUNCE flag >> > was set but BUS_DMA_MIN_ALLOC_COMP not. As bounce pages are never >> > freed, >> > it could cause memory exhaustion when a lot of such tags together >> > with >> > their maps were created. >> > >> > Note that there could be more maps in one tag by current design. >> > However BUS_DMA_MIN_ALLOC_COMP flag is tag's flag. It's set after >> > bounce pages are allocated. Thus, they are allocated only for >> > first >> > tag's map which needs them. >> >> This appears to cause a hang with one of the re(4) interfaces in my >> workstation. I can use it to start an ssh session, but it quickly >> hits a >> point where it stops transmitting or receiving packets, and I need to >> reboot the system to recover. Interestingly, the other re(4) >> interface >> in this system works fine, but it drives a different card: >> >> working: >> re0@pci0:3:0:0: class=0x020000 card=0x85051043 chip=0x816810ec >> rev=0x09 hdr=0x00 >> vendor = 'Realtek Semiconductor Co., Ltd.' >> device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet >> Controller' >> class = network >> subclass = ethernet >> >> non-working: >> re1@pci0:5:0:0: class=0x020000 card=0x816910ec chip=0x816910ec >> rev=0x10 hdr=0x00 >> vendor = 'Realtek Semiconductor Co., Ltd.' >> device = 'RTL8169 PCI Gigabit Ethernet Controller' >> class = network >> subclass = ethernet >> > > With the old logic (which I'm no great defender of beyond "it worked"), > with every map added to a tag, some extra bounce pages would be added > to the tag's bounce zone to account for the new map's needs, up to some > arbitrary #define'd limit. > > With the new logic, it appears that pages will only be added to a > bounce zone one time for each tag, either when the tag is created or > when the first map for the tag is created. After that no more bounce > pages are ever added no matter how many more maps are created for that > tag. So a network driver that creates 1024 maps off a single tag may > have to bounce every single one of those transfers due to alignment but > may have only enough resources to bounce one transfer at a time. > > More likely it will have enough to do several mappings at a time, > because usually there's only one bounce zone being used by all tags and > maps, so extra pages will get added for other tags that will never > bounce, and they'll get consumed by a driver that does need to bounce. > > I would especially expect trouble on ARM where many many mappings need > to bounce due to alignment (but I haven't actually had any trouble > since this change went in). ... uhm, shall we revert this then? This seems very risky. -adrian