Date: Thu, 14 Oct 2010 09:01:29 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Ryan Stone <rysto32@gmail.com> Cc: FreeBSD Current <current@freebsd.org>, freebsd-net@freebsd.org, Attilio Rao <attilio@freebsd.org>, Sergey Kandaurov <pluknet@freebsd.org>, Jack F Vogel <jfv@freebsd.org>, Ryan Stone <rstone@sandvine.com>, Ed Maste <emaste@sandvine.com> Subject: Re: [PATCH] Netdump for review and testing -- preliminary version Message-ID: <C73FFD46-80B0-44F0-9A19-2B047C285134@freebsd.org> In-Reply-To: <AANLkTimisSojDg2z_f1_v71evfooVdPQ44eu2Thhrf3O@mail.gmail.com> References: <AANLkTikA5OUYD1A9pqCqVEZ5qk%2BVECq8x-fnRXnpp0KE@mail.gmail.com> <AANLkTikau6omhWrXVM13zonFEPCxXM%2B8EqJauovDu0OU@mail.gmail.com> <alpine.BSF.2.00.1010090121310.1232@fledge.watson.org> <AANLkTimisSojDg2z_f1_v71evfooVdPQ44eu2Thhrf3O@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Oct 2010, at 18:46, Ryan Stone wrote: > On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson <rwatson@freebsd.org> = 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C73FFD46-80B0-44F0-9A19-2B047C285134>