From: Ted Ts'o <tytso@mit.edu>
To: Jiaying Zhang <jiayingz@google.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: Don't call sb_issue_discard() in ext4_free_blocks()
Date: Tue, 9 Nov 2010 15:03:18 -0500 [thread overview]
Message-ID: <20101109200318.GG3099@thunk.org> (raw)
In-Reply-To: <AANLkTikmExLtH0-LKEvH=WoL=o550EJQuO33dRsoFNWB@mail.gmail.com>
On Tue, Nov 09, 2010 at 10:00:37AM -0800, Jiaying Zhang wrote:
> I would like to spend some time to see whether we can add
> sb_issue_discard() somewhere else for non-journaled mode.
> It is a useful feature to be included for both modes.
It certainly can be done, but we'll have to do the trim from a kernel
thread or workqueue context. (Of course, we need to make sure that
the blocks don't get reused until the trim happens --- or, if we want
to use those blocks, that we take them off the to-be-trimmed list
before we reuse them.)
I am a bit concerned about just adding a new thread, though.
Especially if it's per filesystem, since on a system with a very high
spindle/ext4 file system count, this could get a bit crazy. It's a
bit better in 2.6.36 now that with concurrency managed workqueues,
there's only one workqueue thread per file system, instead of one
workqueue thread per file system per core (so on a system with 50
spindles and 32 cores, there would be 1600 workqueue threads!).
- Ted
prev parent reply other threads:[~2010-11-09 20:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-08 6:06 [PATCH] ext4: Don't call sb_issue_discard() in ext4_free_blocks() Theodore Ts'o
2010-11-09 16:36 ` Eric Sandeen
2010-11-09 18:01 ` Jiaying Zhang
[not found] ` <AANLkTikmExLtH0-LKEvH=WoL=o550EJQuO33dRsoFNWB@mail.gmail.com>
2010-11-09 20:03 ` Ted Ts'o [this message]
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=20101109200318.GG3099@thunk.org \
--to=tytso@mit.edu \
--cc=jiayingz@google.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.