From owner-freebsd-stable@freebsd.org Tue Aug 14 09:18:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92C76107272B for ; Tue, 14 Aug 2018 09:18:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 28A1186955 for ; Tue, 14 Aug 2018 09:18:33 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DAF23107272A; Tue, 14 Aug 2018 09:18:32 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7FC91072729 for ; Tue, 14 Aug 2018 09:18:32 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D22486951; Tue, 14 Aug 2018 09:18:32 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-pg1-f177.google.com with SMTP id f1-v6so8836903pgq.12; Tue, 14 Aug 2018 02:18:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FoHhHoGH7Kr927IjzB+LwD0xcRhtmvjA4NdS86eQWt8=; b=MCtZUyV43IBxQy9LlJlDxgSMGgo/rhC4DyjRvVeSEn/MmQMCTmAbZL60ZWvE28UIqP 1kCfE/FHvxRF6c4HFrObjn0t96ZBm934aVaL0iuAfghxnM/tjpYKAibBDXtCoY8tQhb5 iJujwNDVj0h/4Nh45CmL1WhEMNwa3yAwr3nCSyLCczWjw+OxHFSz42p6Rmlq7avhMl7H JECV2aEfMOZi8XQfNfck0KVGRDT1ePSRy4h+lyhKZ8HThIeNgeE6DnqI5e6Eku+l65LQ E5g5aEsydYuYLiK0Y20MvfJyt9mt8Ni5iQT40cDf0iDjZksdduFpAqmHxFF8zy9uvSM1 /GUQ== X-Gm-Message-State: AOUpUlGEB7f/4zjLMYfUsshvi26xjoZ5srIy8YLMcdGL6xbfO41sMCdR tS2IYM03ZivTHYHOwrv08mP9lnwX X-Google-Smtp-Source: AA+uWPwy+togG8KSbAKZ7XYVH7NmHEEHtUrrGuVMe2LYMFG2qogjYM4w2xi4b08TQ5LmDvuO7PQeXg== X-Received: by 2002:aa7:83cd:: with SMTP id j13-v6mr22591967pfn.236.1534238310849; Tue, 14 Aug 2018 02:18:30 -0700 (PDT) Received: from [192.168.1.36] (broadband-82-140-243-117.atc.tvcom.ru. [82.140.243.117]) by smtp.googlemail.com with ESMTPSA id r19-v6sm33299795pgg.39.2018.08.14.02.18.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 02:18:30 -0700 (PDT) Subject: Re: All the memory eaten away by ZFS 'solaris' malloc - on 11.1-R amd64 To: Mark Martinec , stable@freebsd.org, Alan Somers Cc: Mark Johnston References: <1a039af7758679ba1085934b4fb81b57@ijs.si> <3e56e4de076111c04c2595068ba71eec@ijs.si> <20180731220948.GA97237@raichu> <2ec91ebeaba54fda5e9437f868d4d590@ijs.si> <20180804170154.GA12146@raichu> <87f6a55cc2ee3d754ddb89475bbfbab8@ijs.si> <20180804194757.GD12146@raichu> From: Andriy Gapon Message-ID: <34871f1f-b890-a129-7ead-ed15d8e2e22e@FreeBSD.org> Date: Tue, 14 Aug 2018 12:18:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 09:18:33 -0000 On 07/08/2018 15:58, Mark Martinec wrote: > Collected, here it is: > >   https://www.ijs.si/usr/mark/tmp/dtrace-cmd.out.bz2 I see one memory leak, not sure if it's the only one. It looks like vdev_geom_read_config() leaks all parsed vdev nvlist-s but the last. The problems seems to come from r316760. Before that commit the function would return upon finding the first valid config, but now it keeps iterating. The memory leak should not be a problem when vdev-s are probed sufficiently rarely, but it appears that with an unhealthy pool the probing can happen much more frequently (e.g., every time pools are listed). -- Andriy Gapon