Fine-grained locking for POSIX local sockets (UNIX domain sockets)

[Kris Kennaway]

On Sun, May 14, 2006 at 10:21:45PM +0300, Sven Petai wrote:

> > int
> > chgsbsize(uip, hiwat, to, max)
> >         struct  uidinfo *uip;
> >         u_int  *hiwat;
> >         u_int   to;
> >         rlim_t  max;
> > {
> >         rlim_t new;
> >
> >         UIDINFO_LOCK(uip);
> >
> > So the next question is how can that be optimized?
> >
> > Kris
> 
> hi
> 
> on the 8 core machine this lock was the top contended one with rwatsons patch, 
> with over 8 million failed acquire attempts.
> Originally the unp lock had only ~3 million of those, so this explains the 
> sharp drop with larger number of threads I suppose.
> 
> I feel like I'm missing some very obvious reason, but wouldn't the simplest 
> workaround be just to return 1 right away if limit is set to infinity, which 
> is almost always the case since it's the default, and document on the 
> login.conf manpage that you might take performance hit with this type of 
> workloads when you set sbsize limits.

I tried removing the locking here but did not see a performance
change, so I concluded that it's not actually a bottleneck.

FYI, I have been working on the locking profiling tools quite a bit
lately, and also have started profiling on a 32-thread sun4v system.
I hope to have the patches ready to send out soon (they fix a serious
design error in mutex profiling that makes some of the profiling stats
meaningless, substantially fix performance (20%-25% cost at the moment
instead of >80%), and I also have an implementation of spinlock
profiling using ktr that seems to be extremely cheap).  All of my
other large MP systems are offline though, so the only machines I have
for profiling right now are a dual p4 xeon and Kip Macy's 32-way T1
:-)

> I wonder if I should set up automatic&periodic performance testing
> system, that would run all the tests for example once a week, with
> latest current and stable, so that it would be easier for developers
> to see how changes affect different workloads.
> 
> If you guys think it would be worthwile, what would be the bechmarks
> you would like to see in addition to mysql+supersmack ?

This kind of thing might be a bit tricky to set up, but it would be
well worth it!

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20060603/6125d3f0/attachment.pgp