Reverted in r291193.
On Mon, Nov 23, 2015 at 7:02 AM, Adrian Chadd <adrian.ch...@gmail.com> wrote: > On 22 November 2015 at 20:47, Ian Lepore <i...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
