Date: Mon, 23 Nov 2015 12:21:37 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, Mark Johnston <markj@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r291142 - in head/sys: arm/arm arm64/arm64 mips/mips powerpc/powerpc x86/x86 Message-ID: <CAFHCsPVS0M-a2=TVRpP%2Bp-ZmAKAhibmy_beF7_GtFcvDP3bShg@mail.gmail.com> In-Reply-To: <CAJ-VmokedrB7QYy_%2BO700pDWePzeMw3rk6fiCQDh8NVo0Ct3uw@mail.gmail.com> References: <201511211955.tALJt18a052565@repo.freebsd.org> <20151123032253.GA2084@raichu> <1448254044.1398.22.camel@freebsd.org> <CAJ-VmokedrB7QYy_%2BO700pDWePzeMw3rk6fiCQDh8NVo0Ct3uw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Reverted in r291193. On Mon, Nov 23, 2015 at 7:02 AM, Adrian Chadd <adrian.chadd@gmail.com> wrote: > On 22 November 2015 at 20:47, Ian Lepore <ian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPVS0M-a2=TVRpP%2Bp-ZmAKAhibmy_beF7_GtFcvDP3bShg>