From owner-cvs-all@FreeBSD.ORG Tue Mar 25 22:42:38 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198CD1065678; Tue, 25 Mar 2008 22:42:38 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8835E8FC32; Tue, 25 Mar 2008 22:42:36 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=56706 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JeHqk-000Ejl-So; Tue, 25 Mar 2008 22:42:34 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m2PMgSc9093397; Wed, 26 Mar 2008 01:42:28 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m2PMgSWH093396; Wed, 26 Mar 2008 01:42:28 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Wed, 26 Mar 2008 01:42:28 +0300 From: Ruslan Ermilov To: Alfred Perlstein Message-ID: <20080325224228.GB93187@team.vega.ru> References: <200803250939.m2P9d3RC028128@repoman.freebsd.org> <20080325180152.GB67856@elvis.mu.org> <20080325183750.GA51894@team.vega.ru> <20080325191930.GD67856@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080325191930.GD67856@elvis.mu.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/en midway.c src/sys/dev/fatm if_fatm.c src/sys/dev/firewire if_fwe.c if_fwip.c src/sys/dev/iscsi/initiator isc_soc.c src/sys/kern subr_mchain.c uipc_mbuf.c uipc_socket.c uipc_syscalls.c src/sys/net bpf.c ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 22:42:38 -0000 On Tue, Mar 25, 2008 at 12:19:30PM -0700, Alfred Perlstein wrote: > * Ruslan Ermilov [080325 11:37] wrote: > > On Tue, Mar 25, 2008 at 11:01:52AM -0700, Alfred Perlstein wrote: > > > I don't think this was thought out enough, there are times when you > > > would want to limit the total memory allocated to mbufs and avoid > > > deadlocks in low memory situations. > > > > > > Even the old allocator could have been trivially modified to block > > > forever upon exhaustion of the mbuf arena. > > > > > > The reason why the old allocator was not "fixed" to block forever > > > was to allow for recovery from low memory deadlocks. > > > > > > A lot of work went into making the system safe in the face of these > > > deadlocks and removing it "to clean up" due to a deficiency with > > > the current allocator and without understanding why it was there > > > in the first place is a mistake. > > > > > > This whole thing needs to be backed out. > > > > > Are you (or anyone else you know) planning to work on adding real > > support for M_TRYWAIT? > > I would like to eventually, I think because my place of work moved > from 4.x to 6.x recently it will become an issue for us and we will > need to track it down, this will likely fall on my lap. Presently > the uma panics the machine when exhaustion happens, something that > can be averted by capping mbuf space. > > I spoke to John Baldwin about it and he said "it would be nice" and > would fix a number of panics at his place. That said he seems to > think that this change is OK as we'll just re-add the NULL checks > later on. He doesn't seem to support the backout or not support > it, no idea. > > However I'm not OK with it, because we spent many cycles fixing all > of these and new code will likely just assume the old thing which > will cause it to need substantial refactoring (see NFS history) to > be fixed or re-fixed. > > That said I don't have immediate plans for it, but I see it as a > requirement again as the userbase of 6.x and beyond grows. > Yes, it'd be nice to have the semantics M_TRYWAIT originally supposed to provide, but 1) it never worked as planned, and 2) four years have passed since MBUMA, and the code has rotten: some of it treated M_TRYWAIT as M_WAIT, some as "try to wait" (sometimes mixed in the single file), and some newer code now uses UMA flags M_WAITOK/M_NOWAIT directly, as hinted in mbuf.h. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer