From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 16 00:45:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FE9C6C6; Tue, 16 Oct 2012 00:45:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id DD0A08FC08; Tue, 16 Oct 2012 00:45:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAMisfFCDaFvO/2dsb2JhbABFhhK7C4IgAQEBAwEBAQEgKyALGw4KAgINGQIpAQkmBggHBAEcBIddBguoWJMQgSGKOBqFEYESA5M/gi2BFY8bgwmBRzQ X-IronPort-AV: E=Sophos;i="4.80,592,1344225600"; d="scan'208";a="186531105" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 15 Oct 2012 20:45:13 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E3BCEB410E; Mon, 15 Oct 2012 20:45:13 -0400 (EDT) Date: Mon, 15 Oct 2012 20:45:13 -0400 (EDT) From: Rick Macklem To: Ivan Voras Message-ID: <230083937.2296102.1350348313903.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS server bottlenecks MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 00:45:16 -0000 Ivan Voras wrote: > On 15 October 2012 22:58, Rick Macklem wrote: > > > The problem is that UDP entries very seldom time out (unless the > > NFS server isn't seeing hardly any load) and are mostly trimmed > > because the size exceeds the highwater mark. > > > > With your code, it will clear out all of the entries in the first > > hash buckets that aren't currently busy, until the total count > > drops below the high water mark. (If you monitor a busy server > > with "nfsstat -e -s", you'll see the cache never goes below the > > high water mark, which is 500 by default.) This would delete > > entries of fairly recent requests. > > You are right about that, if testing by Nikolay goes reasonably well, > I'll work on that. > > > If you are going to replace the global LRU list with ones for > > each hash bucket, then you'll have to compare the time stamps > > on the least recently used entries of all the hash buckets and > > then delete those. If you keep the timestamp of the least recent > > one for that hash bucket in the hash bucket head, you could at least > > use that to select which bucket to delete from next, but you'll > > still > > need to: > > - lock that hash bucket > > - delete a few entries from that bucket's lru list > > - unlock hash bucket > > - repeat for various buckets until the count is beloew the high > > water mark > > Ah, I think I get it: is the reliance on the high watermark as a > criteria for cache expiry the reason the list is a LRU instead of an > ordinary unordered list? > Yes, I think you've gt it;-) Have fun with it, rick > > Or something like that. I think you'll find it a lot more work that > > one LRU list and one mutex. Remember that mutex isn't held for long. > > It could be, but the current state of my code is just groundwork for > the next things I have in plan: > > 1) Move the expiry code (the trim function) into a separate thread, > run periodically (or as a callout, I'll need to talk with someone > about which one is cheaper) > > 2) Replace the mutex with a rwlock. The only thing which is preventing > me from doing this right away is the LRU list, since each read access > modifies it (and requires a write lock). This is why I was asking you > if we can do away with the LRU algorithm. > > > Btw, the code looks very nice. (If I was being a style(9) zealot, > > I'd remind you that it likes "return (X);" and not "return X;". > > Thanks, I'll make it more style(9) compliant as I go along. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org"