From owner-freebsd-fs@freebsd.org Sat Nov 28 21:40:52 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 151E5A3B7C7 for ; Sat, 28 Nov 2015 21:40:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B15E51861 for ; Sat, 28 Nov 2015 21:40:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:fcauzB98R512sf9uRHKM819IXTAuvvDOBiVQ1KB92+4cTK2v8tzYMVDF4r011RmSDdidu68P0rCN+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStOU35n8jrrps7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+lh7FVheG4GcdVC08nx5PHhPC8lmuXZDqrir5vOd58CafNMzyC7szXGLxwb1sTUrSiSwEfxsw+2LTh8k42LheqRmioxF665PTb5yYMOJ+OKjUK4BJDVFdV9pcAnQSSri3aJECWq9YZb5V X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQCaHVpW/61jaINVBoQObwa+GAENgWYXCoUkSgKBXxQBAQEBAQEBAYEJgi2CBwEBAQMBAQEBIAQnIAsFCwIBCA4KAgINGQICJwEJJgIECAcEARwEiAUIDawijz0BAQEBAQEBAwEBAQEBAQEYBIEBhVOEfoQ7AQEHBoMrgUQFjSJ2iD+FKoUin0sCHwEBQoIQAR2BdCA0B4QhCBcjgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,357,1444708800"; d="scan'208";a="253175148" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 28 Nov 2015 16:40:44 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id BDF4E15F5E4; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3K7m1gAA5kfi; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 2D6F615F5E9; Sat, 28 Nov 2015 16:40:44 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6yyoidjEOSo3; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 119EC15F5E4; Sat, 28 Nov 2015 16:40:44 -0500 (EST) Date: Sat, 28 Nov 2015 16:40:44 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Cc: FreeBSD FS Message-ID: <1688684587.110043576.1448746844037.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151128142604.GW3448@kib.kiev.ua> References: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca> <20151128142604.GW3448@kib.kiev.ua> Subject: Re: should mutexes be uniquely named? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: should mutexes be uniquely named? Thread-Index: 5NkgetqFhitxRrkMxVU7V9mV7HhHbg== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 21:40:52 -0000 Kostik wrote: > On Sat, Nov 28, 2015 at 08:29:55AM -0500, Rick Macklem wrote: > > Hi, > > > > I think the patches I posted last week that add "-manage-gids" are about > > ready for a commit to head. > > > > However, there is one place in the code where I'm not sure which is better > > to do: > > --> The code replaces a single mutex with one for each hash list head > > (table > > entry). > > I currently use MTX_DUPOK and call them all the same thing. > > or > > I could add a "lockname" field to the hash table enty structure and > > give > > each one a unique name (similar to what Garrett Wollman did in the > > kernel rpc). > > The only downside to this is 16bytes of storage for each hash table > > entry. > > (Admittedly, I don't think many sites would need to set the hash table > > size > > greater than a few thousand, so this isn't a lot of malloc()'d > > memory.) > Question is, why do you need to acquire two mutexes simultaneously ? > If mutexes protect the hash list rooted in head, then this is somewhat > unusual. > There are two hash tables, one hashed on names and the other uid/gid. The entries are linked into both of these lists. I suppose that I could use a different name for the "name" hash table entries vs the "uid/gid" ones, which would avoid the duplication for the common cases. There are also a couple of infrequent cases (when new entries are being added to the cache) where, to avoid a LOR in mutex locking the above 2 hash tables, the code locks all the table entries in the one hash table before doing the other hash table. In this case, you will still end up with duplicates unless each lock is uniquely named. Maybe I should use a different name for the "user/group name" hash table than the "uid/gid" one, but still allow duplicates for the infrequent cases? Thanks for any help, rick > Downside is not only the name, but also a witness overhead in the > non-production kernels. > > > > > > So, what do you think. Should I add the code to make the mutex names > > unique? > > > > Thanks in advance for any comments, rick > > ps: The coding change is trivial. It just involves using more malloc()'d > > memory. > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >