On Jun 21, 2014, at 9:48 PM, Darren Reed <darr...@netbsd.org> wrote:
> On 22/06/2014 8:13 AM, Matt Thomas wrote: >> On Jun 21, 2014, at 4:56 AM, Darren Reed <darr...@netbsd.org> wrote: >>> On 21/06/2014 11:00 AM, Matt Thomas wrote: >>>> On Jun 20, 2014, at 5:57 AM, Ryota Ozaki <ozak...@iij.ad.jp> wrote: >>>> >>>>> Hi, >>>>> >>>>> I've prepared a trial patch of MPSAFE networking. >>>>> >>>>> http://www.netbsd.org/~ozaki-r/mpsafe-wm.diff >>>>> >>>> The kmutex_t in ifqueue, etc. should be pointers and not in the structure >>>> themselves. >>>> That can simply the macros to test for a NULL pointer for the locks in the >>>> non-WM case. >>>> >>>> Consider using mutex_obj_alloc to get mutexes instead of the embedding >>>> them in the >>>> structures. >>> >>> This coding pattern goes against what is done almost everywhere else. >>> >>> What's the rationale behind it? >> >> That's not true. uvm_object's, sockets, etc. all use external kmutex's. >> In this isntance It allows for the ifqueue to use device kmutex is >> there is one. Also, mutexes should be cacheline aligned and that is >> difficult to do in a structure where mutex_obj_alloc does that >> autmoatuiccally. > > Ah, I didn't know that this type of approach was used elsewhere in > NetBSD. Are there any compiler hints that can be embedded in structs > that will result in padding and correct alignment? My solution has > been to always put the lock(s) at the front of a structure. > Can __attribute__((aligned(X)) be used appropriately here or is it > likely to be ignored in the middle of a structure? The problem is that the memory allocators won't honor it since they will return a maximum alignment of ALIGNBYTES+1, where COHERENCY_UNIT can be much higher than that.