From owner-freebsd-fs@FreeBSD.ORG Wed Aug 28 16:40:57 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 70AD89AE; Wed, 28 Aug 2013 16:40:57 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD9B270F; Wed, 28 Aug 2013 16:40:57 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id ha12so4428788vcb.9 for ; Wed, 28 Aug 2013 09:40:56 -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:message-id :subject:to:cc:content-type; bh=0pUJUXgWtnJQUozJSPQTWj89DGpC1GMmt9qnXPY4x2w=; b=tWne3NFlSrHmxKcgtqdth5eXpHIC/50CIAYQhHYD5nkYfuV6s/JcrgLE9wfY1mt1Qi 7q0AiychkTJdpW5A1ZALdkzVaq2Cjjh3anQTT0dLuj0tFmZwkIk7UDhSVBknzVRKz6TB qE2/qMdALJtlC9BpIZVXDkzxxAftBQKQ7115t7Djuaysw8k3Y9IWGAq35dVcieFGUhJ1 /Hk8+YTisTYkIm1flsHvsFYuZh1OMIoC7FJMadaDVHpUK9/w3ClgYsbuAalcxhNfMoO7 PU3KF6tTe877+HmxRi4CJd8sjAJiRX8Nak6UKhqnLWZXGoJVMG0rFFA7Ad82K9C8WmCp isqw== X-Received: by 10.52.165.111 with SMTP id yx15mr1099455vdb.33.1377708056260; Wed, 28 Aug 2013 09:40:56 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.58.229.167 with HTTP; Wed, 28 Aug 2013 09:40:15 -0700 (PDT) In-Reply-To: <20130828181228.0d3618dd@ernst.home> References: <20130828181228.0d3618dd@ernst.home> From: Ivan Voras Date: Wed, 28 Aug 2013 18:40:15 +0200 X-Google-Sender-Auth: U9LZAgQfiX3G_bOqoiVEpR_JU6g Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? To: gljennjohn@googlemail.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs , freebsd-hackers 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: Wed, 28 Aug 2013 16:40:57 -0000 On 28 August 2013 18:12, Gary Jennejohn wrote: > So, if I understand this correctly, a normal desktop user won't > notice any real change, except that buildworld might get faster, > and big servers will benefit? Basically, yes, but read on... > But could this negatively impact small, embedded systems, which > usually have only small memory footprints? Although I suppose > one could argue that they usually don't have large numbers of > files cached in memory at any given time. Unless I'm wrong, the only pathological case coming from this change would be the following sequence of events: 1) Memory is scarce [*] 2) There's a sudden surge of requests for a huge number of different directories 3) There's an urgent lowmem event which is observed by dirhash, which attempts to free memory but is prevented in doing so for the next 60 seconds because all entries are young (the idea behind dirhash being that if a directory is accessed, it will probably soon be accessed again - think "ls" then "fopen", so we won't evict him until reclaimage seconds) 4) the kernel runs out of memory, game over. Note that this sequence of events could still happen right now, only over a span of 5 seconds, not 60 seconds. Note also that all of this has nothing to do with regular file cache, dirhash is a very specific corner-case of UFS. [*] Keep in mind that dirhash cache even on large and busy systems is usually ~~15-25 MB; on 16 GB machines the auto-tuning code caps it at 25 MB. As an illustration on how tiny dirhash is: a "du -c" on /usr/ports increases dirhash_mem on my desktop from 103945 to 501507 bytes. One of the issues raised by davide is that the benefits from this are also miniscule and hard to prove. A simple buildworld is not a big enough load. I've seen on my own skin how increasing reclaimage helped, but that was under such specific circumstances that I'm still trying to figure out how to create a self-sustained benchmark (basically - how to provoke lowmem events?). Basically, this change will have no effect for 99.9% of users, but could save that 0.1% from going crazy.