[RFC] Bumping ufs.dirhash_maxmem to a larger value?

From: Xin LI (delphij_at_frontfree.net)
Date: 08/07/05

  • Next message: Chuck Swiger: "Re: [RFC] Bumping ufs.dirhash_maxmem to a larger value?" 
    Date: Mon, 8 Aug 2005 02:47:07 +0800
To: freebsd-performance@FreeBSD.org

    [Bcc'ed to -developers@, so this can be discussed in a public list]

    Hi,

    It seems that vfs.ufs.dirhash_maxmem is set to 2MB. I think this value
    is slightly too small for modern machines:
     - There are many applications that relies on small files. CVS, maildir,
       etc. For these applications a typical need of dirhash would be much
       larger than 2MB.
     - The RAM equiped with modern computers are growing fast.
     - Increasing dirhash_maxmem does not bring too much overhead on small
       systems, as the system would automatically recycle unused entities.
       If the memory was not freed in time, then it is usually because
       the system is busy accessing a zillion of small files. Moreover,
       it is possible for the user to change the default value back to
       a smaller value if the file indexing is not their performance
       bottleneck.

    My proposal is to increase the default dirhash_maxmem value to at least
    32MB or 64MB. Any objections?

    Cons for this, discussed in -developer:
     - dirhash does not implements automatical mechanism to reduce memory
       usage in response to system memory pressure, and benefits mainly to
       large directories, e.g. Maildirs.

    Cheers, 

    -- 
Xin LI <delphij frontfree net>	http://www.delphij.net/
See complete headers for GPG key and other information.

  • Next message: Chuck Swiger: "Re: [RFC] Bumping ufs.dirhash_maxmem to a larger value?"

    Relevant Pages

    • Re: xmalloc string functions
      ... require memory allocations depending on the way the system works. ... If the toolkit being used is not one of those, then it is irrelevant that some provide a means to do so, particularly if the "some" are not available for the platform being targeted. ... Not enough context for most real-world applications to recover at this point. ... At this point g_malloccalling abortbecomes a moot point, particularly if your auto-save code is robust against memory allocation errors. ...
      (comp.lang.c)
    • Re: ProDOS Plus
      ... operating system was not considered worth the problems when it was just as easy to make the applications support 128k or more ram. ... your suggested P-code system could do something similar by running in the aux 64k memory range $D000...FFFF or perhaps the aux ram used by the P8 /ram driver code space. ... the OS could fit in *only* the space that ProDOS now occupies. ... if practicality were a concern we probably wouldn't be using old hardware. ...
      (comp.sys.apple2)
    • Re: xmalloc string functions
      ... If these were the only choices (crashing applications or a frozen ... trying to malloc some rediculously large amount of memory - e.g. in the ... because their malloc wrapper decided to exit. ... Exiting on malloc failure makes sense for a utility like sort. ...
      (comp.lang.c)
    • Re: xmalloc string functions
      ... require memory allocations depending on the way the system works. ... Not enough context for most real-world applications to ... It is /more/ reliable to routinely auto-save the user's work (as you ... particularly if your auto-save code is robust against memory allocation ...
      (comp.lang.c)
    • RE: DLLHOST.EXE and Secure Server Crash
      ... This is a very common problem with COM+ components and IIS. ... | Applications view switch to Status View) ... |>with 2-3 dedicated SSL servers. ... A symptom of the problem centers around memory ...
      (microsoft.public.inetserver.iis.security)