From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 08:01:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F8011065673; Thu, 14 Oct 2010 08:01:34 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 402018FC1C; Thu, 14 Oct 2010 08:01:34 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 368C646B2E; Thu, 14 Oct 2010 04:01:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 14 Oct 2010 09:01:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Stone X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 08:01:34 -0000 On 13 Oct 2010, at 18:46, Ryan Stone wrote: > On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson = wrote: >> + /* >> + * get and fill a header mbuf, then chain data as an >> extended >> + * mbuf. >> + */ >> + MGETHDR(m, M_DONTWAIT, MT_DATA); >>=20 >> The idea of calling into the mbuf allocator in this context is just = freaky, >> and may have some truly awful side effects. I suppose this is the = cost of >> trying to combine code paths in the network device driver rather than = have >> an independent path in the netdump case, but it's quite unfortunate = and will >> significantly reduce the robustness of netdumps in the face of, for = example, >> mbuf starvation. >=20 > Changing this will require very invasive changes to the network > drivers. I know that the Intel drivers allocate their own mbufs for > their receive rings and I imagine that all other drivers have to do > something similar. Plus the drivers are responsible for freeing mbufs > after they have been transmitted. It seems to me that the cost of > making significant changes to the network drivers to support an > alternate lifecycle for netdump mbufs far outweighs the cost of losing > a couple of kernel dumps in extreme circumstances. My concern is less about occasional lost dumps that destabilising the = dumping process: calls into the memory allocator can currently trigger a = lot of interesting behaviours, such as further calls back into the VM = system, which can then trigger calls into other subsystems. What I'm = suggesting is that if we want the mbuf allocator to be useful in this = context, we need to teach it about things not to do in the dumping / = crash / ... context, which probably means helping uma out a bit in that = regard. And a watchdog to make sure the dump is making progress. Robert=