From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 04:24:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9195A8FA for ; Mon, 12 Nov 2012 04:24:36 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1788FC12 for ; Mon, 12 Nov 2012 04:24:36 +0000 (UTC) Received: from [10.245.102.125] (148.sub-174-253-233.myvzw.com [174.253.233.148]) by elvis.mu.org (Postfix) with ESMTPSA id D1ED11A3C54; Sun, 11 Nov 2012 20:24:34 -0800 (PST) References: <20121112003215.238950@gmx.com> In-Reply-To: <20121112003215.238950@gmx.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2CB113BD-D223-4BCF-AAB8-F3D3FA962168@mu.org> X-Mailer: iPhone Mail (9B206) From: Alfred Perlstein Subject: Re: Memory reserves or lack thereof Date: Sun, 11 Nov 2012 20:24:31 -0800 To: Dieter BSD Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 04:24:36 -0000 I think very few of the m_nowaits actually need the reserve behavior. We sho= uld probably switch away from it digging that deep by default and introduce a= flag and/or a per thread flag to set the behavior.=20 Sent from my iPhone On Nov 11, 2012, at 4:32 PM, "Dieter BSD" wrote: > Alan writes: >> In conclusion, I think it's time that we change M_NOWAIT so that it doesn= 't >> dig any deeper into the cache/free page queues than M_WAITOK does and >> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >> cache/free page queues. The trouble is that we then need to identify all= >> of those places that are implicitly depending on the current behavior of >> M_NOWAIT also digging deep into the cache/free page queues so that we can= >> add an explicit M_USE_RESERVE. >=20 > find /usr/src/sys | xargs grep M_NOWAIT | wc -l > 2101 >=20 > Sounds like a lot of work that would need to happen atomically. > Would this work: >=20 > M_NO_WAIT do not sleep, do not dig deep unless M_USE_RESERVE also se= t > M_USE_RESERVE dig deep > M_NOWAIT M_NO_WAIT | M_USE_RESERVE (deprecated) >=20 > New code avoids using M_NOWAIT. Existing code continues working the same w= ay. > As time permits, old code is converted to new flags. Eventually M_NOWAIT > goes away. >=20 > Pro: the amount of code that needs to change atomically is much smaller. >=20 > Con: (1) Have to remember (or look up) difference between M_NOWAIT > and M_NO_WAIT. Maybe calling the new flag M_NO_SLEEP would help? > (2) Would M_NOWAIT really ever go away? The spl() calls haven't, > even after some cage rattling. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=