From owner-freebsd-arch Mon Dec 4 20:45:19 2000 From owner-freebsd-arch@FreeBSD.ORG Mon Dec 4 20:45:17 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 69B3037B400 for ; Mon, 4 Dec 2000 20:45:13 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA42725; Mon, 4 Dec 2000 21:44:38 -0700 (MST) (envelope-from ken) Date: Mon, 4 Dec 2000 21:44:38 -0700 From: "Kenneth D. Merry" To: Bosko Milekic Cc: arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <20001204214438.A42689@panzer.kdm.org> References: <20001201002235.D10772@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bmilekic@technokratis.com on Sat, Dec 02, 2000 at 01:00:22PM -0500 Sender: ken@panzer.kdm.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ catching up with mail from this weekend ] On Sat, Dec 02, 2000 at 13:00:22 -0500, Bosko Milekic wrote: > > On Fri, 1 Dec 2000, Kenneth D. Merry wrote: > > > It does have spls in the right places, in this case splimp() and splvm(). > > Would you just convert those to the proper mutexes, or are we going to go > > with per-data-structure mutexes (i.e. a little finer granularity), or...? > > (I don't know much about the mutex strategy we're using...) > > For now, you won't be able to do anything with the splvm() stuff, as > the VM code has not yet been ripped out from under Giant (and likely > won't be for a while). > A few notes Re: spl()s and mutexes in uipc_jumbo.c, in particular > (since that's where I would begin putting in mutexes): > > - Your jumbo_kmap singly linked list should probably not be manipulated > under splvm() [in fact, I think it's wrong]. The list should be > protected by a lock. Okay. > - jumbo_freem should just be called jumbo_free, if the naming convention > is being adopted from the mbuf system (which it looks like it is). The > reason is that for mbufs, m_free() frees a single mbuf while m_freem() > frees an entire chain of them. Okay. > - jumbo_pg_free should be ripped out from under splimp(); leave the > explicit splvm() in there, but protect the list manipulations with the > lock. Okay. > If most of the things pointed out earlier are fixed, and as long as > the code is not flawed (which I really doubt it would be anyway), I have > no objections to it going in soon and then attacking the above issue a > little later (If nobody gets to it within the next two weeks, I'll be > glad to do it myself once those 2 weeks are past). Sounds good. There have been other problems pointed out that we'll need to fix as well before the code can go in. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message