Date: Sat, 18 May 2002 16:41:22 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Alfred Perlstein <bright@mu.org>, "Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets patches available Message-ID: <3CE6E6A2.4A42228B@mindspring.com> References: <XFMail.20020518192148.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On 18-May-2002 Terry Lambert wrote: > > John Baldwin wrote: > >> > God, it's annoying that a statically declared mutex is not > >> > defacto initialized. > >> > >> Is it in solaris? > > > > It isn't in FreeBSD because of the need to link mutex'es into > > the "witness protection program". 8-). > > Actually, there is more to it than that. Or at least, there will be > when turnstiles are added (turnstiles require some function callouts > to work properly). It's the function callouts that are the problem. 8-(. > > MUTEX_DECLARE(mutex_name). > > Umm, yes, like MTX_SYSINIT(). :) No. An MTX_SYSINIT() that wrapped a declaration and a SYSINIT() would als imply the definition of an static function to do the initialization, that then got called by the SYSINIT() itself. This is actually what I was saying was bad: a static function per mutex declaration. You really want to avoid the pthreads "mutex initializer" thing; the compiler doesn't have code that can attach to data declarations to fix the problem. So, among other things, you want to use the same initializer function instance for all statically declared mutexes. So you have to use something other than a SYSINIT() for the declarations, but you could use *one SYSINIT()* to do the pre-use initialization of *all* declarations. > > You could do this with a SYSINIT(), as has been suggested, but > > that would add a relatively large per mutex overhead for each > > one you want to declare, since you'd basically be repeating the > > common components for doing the job for each and every mutex, > > instead of sharing them. > > Umm, this is a boot-up thing so it's not that big of a deal, plus > the actual code isn't duplicated, we call a common function for > the actual mutex initialization. Maybe. I don't think a large sysinit structure is as useful as an array of addresses of mutexes needing initialization. There would be a serious tempation in the former case to provide for some type of non-uniform initialization of statically declared sysinit objects. It would be nice if the non-uniformity could be limited to the fact that if the WITNESS code was there, it needed to be linked onto the list. With the WITNESS code not compiled into the kernel, I'd prefer not to include the initialization code at all. It would encorage bad practice, if it weren't conditional on WITNESS. > > Technically, some later programmer could come along and recover > > the linker set memory, actually, since it's only used once, for > > the traversal, at kernel startup. > > Erm, they could do the same with the little mtx_args structs if > they want to as well, but I think it's more effor than its worth. Actually, I don't think they could. The intermediate stage for that would really suck. The only way to handle it is to use different ELF sections for that datam so that you could discard the section later. This is worthwhile for device probe code, maybe attach code, any linker set contents, but not really for individial small structures each getting jammed into their own page size object. 8-). You'd need to do a lot more work, including KVA defragmentation by being able to sectionally attribute anything in the paging path, to keep it from being moved around, or the move-it-around code itself. -- Terry 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?3CE6E6A2.4A42228B>