All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Webb <chris@arachsys.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: linux-bcachefs@vger.kernel.org
Subject: Re: More eager discard behaviour
Date: Sat, 6 Nov 2021 21:36:50 +0000	[thread overview]
Message-ID: <20211106213649.GN11670@arachsys.com> (raw)
In-Reply-To: <YYbZii7HNJ8lb8FF@moria.home.lan>

Kent Overstreet <kent.overstreet@gmail.com> writes:

> On Sat, Nov 06, 2021 at 05:11:56PM +0000, Chris Webb wrote:
> > How practical would it be either to more-greedily wake the allocator thread
> > and reclaim buckets, or to detect buckets available to discard earlier in
> > their lifetime?
> 
> It's on the todo list, it'll be part of the grand allocator rework I have
> planned - there's a lot that needs to be done.

I read your discussion on the status update and in the related write-up on
the accounting code. It makes a lot of sense to me, given the tried and
tested btree layer is there to be used.

> We've got to rework the state transitions, and differentiate between buckets
> with cached data, buckets that need a journal commit before we can write to them
> again, buckets that need discarding, and buckets that are ready for use - and we
> need to start storing all that persistently, as well as build some new data
> structures to get rid of the scanning over every bucket we currently have to do
> in various places.
> 
> Step one is going to be creating a persistent LRU. It'll be another btree,
> sorted by the order in which we want to reuse buckets - a combination of the
> amount of live data in the bucket and the time since it was last read.
> 
> If you're interested in tackling this, I can sketch it out for you :)

I'm definitely interested in helping out if I can, although there's a slight
risk of biting off more than I can chew: I probably understand even less
about the design and structure of your fs at the moment than you think!

I don't want to be a slow-moving obstacle on your critical path or more of a
nuisance than a help, but equally, getting stuck in is clearly the best way
to figure out how it fits together and become more useful. So happy to give
anything a go that you think is reasonable for a newcomer to take a crack
at. :) 

Best wishes,

Chris.

  reply	other threads:[~2021-11-06 21:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-06 17:11 More eager discard behaviour Chris Webb
2021-11-06 19:37 ` Kent Overstreet
2021-11-06 21:36   ` Chris Webb [this message]
2021-11-07 14:59     ` Kent Overstreet
2021-11-08 21:16       ` Chris Webb

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=20211106213649.GN11670@arachsys.com \
    --to=chris@arachsys.com \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-bcachefs@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.