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

On Monday 08 May 2006 09:52, Kris Kennaway wrote:

>  The other big gain is to sleep
> mtxpool contention, which roughly doubled:
>
> /*
>  * Change the total socket buffer size a user has used.
>  */
> 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.

--- /usr/src/sys_clean/kern/kern_resource.c     Sat Mar 11 12:48:19 2006
+++ /usr/src/sys/kern/kern_resource.c   Sun May 14 05:34:02 2006
_at__at_ -1169,6 +1169,10 _at__at_
 {
        rlim_t new;

+       if (max == RLIM_INFINITY) {
+               *hiwat = to;
+               return (1);
+       }
        UIDINFO_LOCK(uip);
        new = uip->ui_sbsize + to - *hiwat;
        /* Don't allow them to exceed max, but allow subtraction. */

8 core machine that I originally used for benchmarking was
shipped out to client, so I couldn't test how it would have
performed with uidinfo contention out of the way, but results from
a 1 * dualcore machine look good:
http://bsd.ee/~hadara/debug/mysql4/dualcore/stats.html

Several interesting things can be noticed from this data
 * on dualcore rwatsons patch gives consistent performance boost
   with all the thread settings tested, no sharp drop after 20 that I had on
   8 core
 * with threadcount in range [3;10] even number of
   threads performs usually ~4-5% better than odd number
 * with uidinfo + rwatson patch there were some significant outliers
   where one result was more than 30% better than others with same
   settings, these were removed before calculating mean values for graphs

after I had finished benchmarking I discovered that new malloc library has 
debug turned on. After turning it off I see large (20-25%) performance boosts 
across the range, so I started new round of testing with NO_MALLOC_EXTRAS 
defined, I'll update the results ASAP.


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 ?