From owner-freebsd-fs@FreeBSD.ORG Sun Oct 14 00:16:18 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C09F84F1 for ; Sun, 14 Oct 2012 00:16:18 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6D88FC08 for ; Sun, 14 Oct 2012 00:16:18 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so6029720vcb.13 for ; Sat, 13 Oct 2012 17:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8ZPNwFWSu4oLIfM2pk34cMcz1aqJ9zBgeC8cV5tXv0M=; b=sD+dV5McU2+UlET0LJxxWD0PKyucorFFgHC+Ab5MOftC9qZE1+GHjom9EOV0dVkstL /Iiu0J9ylltLL/gEu4sZqt3b9Pbi/Mn2+DZNBo1rNCvRvTizqX2KZ9CtyDWj0BKfYjGI m6HzfuBfO79T+IFcJ/5k7oqgPb/YfNg4+PoVvQ1KWTxn3zpOWv/6MBrTkqBdGPPz8f6w Cu8OgKAPP47sA8LplVSBaaQ6ihHIDjs03SQvXb+1nfWB1/YESOr4kDl02aZDUYXm0+l0 rwWg4W+TmgFY65/ckR+Fc6TRKVBUAq/rhw2+217sTfTpPsoALidQMETrSYUdtjWwgBfp eqHA== Received: by 10.52.139.136 with SMTP id qy8mr3803800vdb.39.1350173777557; Sat, 13 Oct 2012 17:16:17 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.59.0.37 with HTTP; Sat, 13 Oct 2012 17:15:37 -0700 (PDT) In-Reply-To: <1979889899.2197790.1350164598183.JavaMail.root@erie.cs.uoguelph.ca> References: <1979889899.2197790.1350164598183.JavaMail.root@erie.cs.uoguelph.ca> From: Ivan Voras Date: Sun, 14 Oct 2012 02:15:37 +0200 X-Google-Sender-Auth: T7c0cVYz-7WGiAu0hTkhqJ-87vg Message-ID: Subject: Re: NFS server bottlenecks To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Cc: FS List X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 00:16:18 -0000 On 13 October 2012 23:43, Rick Macklem wrote: > If, as you proposed, use separate LRU lists for each hash bucket, then > how do you know if the least recently used for one hash backet isn't > much more recently used than the least recently used for another hash > bucket? (The hash code is using xid, which might be about the same for > different clients at the same time.) I'm not that familiar with the code to judge: would that be a problem, other than a (seemingly slight) loss of efficiency? Is there any other purpose to the LRU list except to help remove stale entries? I haven't done any real examination of how it works, but looking at the code in: http://fxr.watson.org/fxr/source/fs/nfsserver/nfs_nfsdcache.c#L780 ... I don't see how the LRU property of the list actually helps anything (I.e. - would the correctness of the code be damaged if this was an orfinary list without the LRU property?) > ps: I hope you didn't mind me adding the mailing list. I'd like others to > be able to comment/read the discussion. For the others to catch up, I was proposing this approach to Rick: http://people.freebsd.org/~ivoras/diffs/nfscache_lock.patch (this patch is far from being complete, it's just a sketch of an idea). Basically, I'd like to break the global hash lock into per-bucket locks and to break the global LRU list into per-bucket lists, protected by the same locks.