Date: Mon, 4 Dec 2000 21:44:38 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Bosko Milekic <bmilekic@technokratis.com> Cc: arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <20001204214438.A42689@panzer.kdm.org> In-Reply-To: <Pine.BSF.4.21.0012021237540.91517-100000@jehovah.technokratis.com>; from bmilekic@technokratis.com on Sat, Dec 02, 2000 at 01:00:22PM -0500 References: <20001201002235.D10772@panzer.kdm.org> <Pine.BSF.4.21.0012021237540.91517-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001204214438.A42689>