b_freelist TAILQ/SLIST
Alexander Motin
mav at FreeBSD.org
Thu Jun 27 21:26:50 UTC 2013
Hi.
While doing some profiles of GEOM/CAM IOPS scalability, on some test
patterns I've noticed serious congestion with spinning on global
pbuf_mtx mutex inside getpbuf() and relpbuf(). Since that code is
already very simple, I've tried to optimize probably the only thing
possible there: switch bswlist from TAILQ to SLIST. As I can see,
b_freelist field of struct buf is really used as TAILQ in some other
places, so I've just added another SLIST_ENTRY field. And result
appeared to be surprising -- I can no longer reproduce the issue at all.
May be it was just unlucky synchronization of specific test, but I've
seen in on two different systems and rechecked results with/without
patch three times.
The present patch is here:
http://people.freebsd.org/~mav/buf_slist.patch
The question is how to do it better? What is the KPI/KBI policy for
struct buf? I could replace b_freelist by a union and keep KBI, but
partially break KPI. Or I could add another field, probably breaking
KBI, but keeping KPI. Or I could do something handmade with no breakage.
Or this change is just a bad idea?
--
Alexander Motin
More information about the freebsd-hackers
mailing list