Date: Wed, 19 Jun 2002 12:06:41 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Dag-Erling Smorgrav <des@ofug.org>, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619120641.A18434@unixdaemons.com> In-Reply-To: <20020619090046.A2063@panzer.kdm.org>; from ken@kdm.org on Wed, Jun 19, 2002 at 09:00:46AM -0600 References: <20020618223635.A98350@panzer.kdm.org> <xzpelf3ida1.fsf@flood.ping.uio.no> <20020619090046.A2063@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 19, 2002 at 09:00:46AM -0600, Kenneth D. Merry wrote:
> On Wed, Jun 19, 2002 at 15:55:18 +0200, Dag-Erling Smorgrav wrote:
> > "Kenneth D. Merry" <ken@kdm.org> writes:
> > > With those fixes, plus several fixes that have gone into -current over the
> > > past week or so, the zero copy sockets code runs without any WITNESS
> > > warnings at all now.
> >
> > Planning to commit soon?
>
> That's the plan. I need to see if any comments come up, and then make sure
> I'll be in town for a few days at least to handle any problems that come
> up.
I have a few comments and questions:
- In uipc_jumbo.c, you appear to avoid using some of the SLIST macros,
notably when grabbing something off the inuse or free lists.
- Is the mutex really necessary in jumbo_vm_init()? I suspect that
if you need to ensure mutual exclusion here, there's something
wrong; (why would you be running the jumbo vm code before having
initialized it?) - perhaps you could init the mtx at runtime in the
jumbo_vm_init routine.
- It's kind of unfortunate that uipc_jumbo.c has to roll its own
allocator; There are a couple of alternatives; to just use
UMA or mb_alloc for this sort of thing. mb_alloc will wire
all pages allocated through it, though, so maybe it would be worth
looking at what UMA can do in this respect. If it cannot do exactly
what you're looking for, then modifying it to do what you want
should be relatively simple. The added advantage is that you'll now
be using per-CPU caches for allocations of jumbo bufs, and not the
single freelist that you currently use.
- I don't know anything about the if_ti code, but it sure looks like
it's holding the ti mutex a long time in some places (not only in
your patch).
> Ken
> --
> Kenneth Merry
> ken@kdm.org
Regards,
--
Bosko Milekic
bmilekic@unixdaemons.com
bmilekic@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020619120641.A18434>