All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Josef Bacik <josef@redhat.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: save preloaded extent_state's in a percpu cache V2
Date: Tue, 21 Jun 2011 13:20:39 -0700	[thread overview]
Message-ID: <m2sjr32ay0.fsf@firstfloor.org> (raw)
In-Reply-To: <1308670095-15480-1-git-send-email-josef@redhat.com> (Josef Bacik's message of "Tue, 21 Jun 2011 11:28:15 -0400")

Josef Bacik <josef@redhat.com> writes:

> When doing DIO tracing I noticed we were doing a ton of allocations, a lot of
> the time for extent_states.  Some of the time we don't even use the prealloc'ed
> extent_state, it just get's free'd up.  So instead create a per-cpu cache like
> the radix tree stuff.  So we will check to see if our per-cpu cache has a
> prealloc'ed extent_state in it and if so we just continue, else we alloc a new
> one and fill the cache.  Then if we need to use a prealloc'ed extent_state we
> can just take it out of our per-cpu cache.  We will also refill the cache on
> free to try and limit the number of times we have to ask the allocator for
> caches.  With this patch dbench 50 goes from ~210 mb/s to ~260 mb/s.  Thanks,

You're just reimplementing a poor man's custom slab cache -- all of this is already
done in slab.

If the difference is really that big better fix slab and have everyone 
benefit?

Did you use slub or slab?
Did you analyze where the cycles are spent?

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

  reply	other threads:[~2011-06-21 20:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21 15:28 [PATCH] Btrfs: save preloaded extent_state's in a percpu cache V2 Josef Bacik
2011-06-21 20:20 ` Andi Kleen [this message]
2011-06-21 21:25   ` Josef Bacik

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=m2sjr32ay0.fsf@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.