From owner-freebsd-arch Sat Dec 2 9:59:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 49A0A37B400 for ; Sat, 2 Dec 2000 09:59:39 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G4Y005JNCNC4R@falla.videotron.net> for arch@FreeBSD.ORG; Sat, 2 Dec 2000 12:59:36 -0500 (EST) Date: Sat, 02 Dec 2000 13:00:22 -0500 (EST) From: Bosko Milekic Subject: Re: zero copy code review In-reply-to: <20001201002235.D10772@panzer.kdm.org> To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. - 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. - jumbo_pg_free should be ripped out from under splimp(); leave the explicit splvm() in there, but protect the list manipulations with the lock. 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). Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message