From owner-svn-src-all@freebsd.org Mon Nov 23 11:21:38 2015 Return-Path: Delivered-To: svn-src-all@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 0D81FA3552A; Mon, 23 Nov 2015 11:21:38 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 CC2201E48; Mon, 23 Nov 2015 11:21:37 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by igcmv3 with SMTP id mv3so26405747igc.0; Mon, 23 Nov 2015 03:21:37 -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=V+T9UuNLg1Uc5VH6jelOeyd78fJCm1vDDNWBqyk6hv0=; b=exchIQ44xHwkBWFTjcY9kT1y+CNQ8WAuYPIPsnvZ+fgxgCsldyNO/QXwFe62jbm7yT 7R7PdUxktsLAh9Rz5tUFHPcK5Od3hpu0xi/Ayc8Ye31njUlQgr71YSTUmHutl0tqELhm h3XCtzTnyTjq4v/PI6ulHC9JvYbsBJSM1BM1xpnu020duZBBUsEouQji5KrgID9r6Wl0 hQfy+y9+O/wQ+F0YzXU8H4ZUm3BO9KwPS/kJEfhT53eCDXINhyg/pmA8pwaY+NoEnXBf 6LPG/KTYEIrLt8XyEXv6VCH5ZH1dRimRtLmiQjdzJycmmaEwp/zcb69k4p3Ihe9LXcHH RiEw== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr10668319igl.19.1448277697270; Mon, 23 Nov 2015 03:21:37 -0800 (PST) Received: by 10.64.130.38 with HTTP; Mon, 23 Nov 2015 03:21:37 -0800 (PST) In-Reply-To: References: <201511211955.tALJt18a052565@repo.freebsd.org> <20151123032253.GA2084@raichu> <1448254044.1398.22.camel@freebsd.org> Date: Mon, 23 Nov 2015 12:21:37 +0100 Message-ID: Subject: Re: svn commit: r291142 - in head/sys: arm/arm arm64/arm64 mips/mips powerpc/powerpc x86/x86 From: Svatopluk Kraus To: Adrian Chadd Cc: Ian Lepore , Mark Johnston , "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-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 11:21:38 -0000 Reverted in r291193. On Mon, Nov 23, 2015 at 7:02 AM, Adrian Chadd wrote: > 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