All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: Don't allow lg prealloc list to be grow large.
Date: Wed, 23 Jul 2008 14:13:27 -0400	[thread overview]
Message-ID: <20080723181327.GA27683@mit.edu> (raw)
In-Reply-To: <1216833047-4959-4-git-send-email-aneesh.kumar@linux.vnet.ibm.com>

On Wed, Jul 23, 2008 at 10:40:47PM +0530, Aneesh Kumar K.V wrote:
> Currently locality group prealloc list is freed only when there is a block allocation
> failure. This can result in large number of per cpu locality group prealloc space
> and also make the ext4_mb_use_preallocated expensive. Convert the locality group
> prealloc list to a hash list. The hash index is the order of number of blocks
> in the prealloc space with a max order of 9. When adding prealloc space to the
> list we make sure total entries for each order does not exceed 8. If it is more
> than 8 we discard few entries and make sure the we have only <= 5 entries.

So the second sentence made my english parser core dump.  :-)

I rewrote the patch comments as follows; is it still a fair summary?

    Currently, the locality group prealloc list is freed only when there
    is a block allocation failure. This can result in large number of
    entries in the preallocation list making ext4_mb_use_preallocated()
    expensive.
    
    To fix this, we convert the locality group prealloc list to a hash
    list. The hash index is the order of number of blocks in the prealloc
    space with a max order of 9. When adding prealloc space to the list we
    make sure total entries for each order does not exceed 8. If it is
    more than 8 we discard few entries and make sure the we have only <= 5
    entries.

							- Ted

  reply	other threads:[~2008-07-23 18:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-23 17:10 Patches for patchqueue Aneesh Kumar K.V
2008-07-23 17:10 ` [PATCH] ext4: Improve error handling in mballoc Aneesh Kumar K.V
2008-07-23 17:10   ` [PATCH] ext4: Convert the usage of NR_CPUS to nr_cpu_ids Aneesh Kumar K.V
2008-07-23 17:10     ` [PATCH] ext4: Don't allow lg prealloc list to be grow large Aneesh Kumar K.V
2008-07-23 18:13       ` Theodore Tso [this message]
2008-07-23 17:49 ` Patches for patchqueue Theodore Tso
  -- strict thread matches above, loose matches on Subject: below --
2008-07-22 11:10 [PATCH] ext4: Don't allow lg prealloc list to be grow large Aneesh Kumar K.V
2008-07-22 12:36 ` Aneesh Kumar K.V
2008-07-22 17:42 ` Eric Sandeen
2008-07-21  9:40 Aneesh Kumar K.V
2008-07-21 19:37 ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080723181327.GA27683@mit.edu \
    --to=tytso@mit.edu \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.