From: Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Brad Walker <bwalker-WlSugiYO8JFBDgjK7y7TUQ@public.gmane.org>
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: problem w/ read caching..
Date: Mon, 1 Oct 2012 16:00:23 -0700 [thread overview]
Message-ID: <20121001230023.GG26488@google.com> (raw)
In-Reply-To: <loom.20121002T001556-394-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
On Mon, Oct 01, 2012 at 10:26:43PM +0000, Brad Walker wrote:
> Kent Overstreet <koverstreet@...> writes:
>
>
> > I was just browsing around the code, and I bet I know what it is -
> > btree_insert_check_key() is failing because the btree node is full.
> >
> > But, we should confirm this really is what's going on... Can you apply
> > this patch and rerun to test my theory? See if the number of times the
> > printk fires lines up with the number of cache misses.
> >
>
>
> I applied this change and I see a LOT of the messages.
>
> And the rate seems to be increasing.
Sweet, we know what it is then.
So, like I mentioned this won't be an issue on any workload with mixed
read/writes, so if that's what your production workloads are then this
may not matter to you.
For warming up the cache, doing a few random writes (just enough that
you hit all the btree nodes - and there aren't many btree nodes, cat
internel/btree_nodes) will fix it.
A real fix for this shouldn't be too hard, but it's not exactly trivial
and it'll be a pain to test... not quite sure when I'll get to it, but
it would be good to have it fixed.
next prev parent reply other threads:[~2012-10-01 23:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 20:01 problem w/ read caching Brad Walker
[not found] ` <CAPKZHbV3n7O+VRVNS-C2oDVSpO_VdirMDUOuwwWKaA5ZOUEG_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-13 18:43 ` Kent Overstreet
2012-09-27 23:28 ` Brad Walker
[not found] ` <loom.20120928T010314-562-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-09-28 18:59 ` Kent Overstreet
2012-10-01 19:18 ` Brad Walker
[not found] ` <loom.20121001T211315-779-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-10-01 19:38 ` Kent Overstreet
2012-10-01 20:05 ` Brad Walker
[not found] ` <loom.20121001T220412-225-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-10-01 20:37 ` Kent Overstreet
2012-10-01 20:56 ` Brad Walker
[not found] ` <loom.20121001T223817-249-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-10-01 21:14 ` Kent Overstreet
2012-10-01 22:26 ` Brad Walker
[not found] ` <loom.20121002T001556-394-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2012-10-01 23:00 ` Kent Overstreet [this message]
[not found] ` <20121001230023.GG26488-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-10-03 4:44 ` Kent Overstreet
2012-10-08 16:39 ` Brad Walker
[not found] <50651c68.a8e1440a.1165.67c8SMTPIN_ADDED@mx.google.com>
[not found] ` <50651c68.a8e1440a.1165.67c8SMTPIN_ADDED-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2012-09-28 16:31 ` Brad Walker
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=20121001230023.GG26488@google.com \
--to=koverstreet-hpiqsd4aklfqt0dzr+alfa@public.gmane.org \
--cc=bwalker-WlSugiYO8JFBDgjK7y7TUQ@public.gmane.org \
--cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.