All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/7 v2] ext4: extent status tree (step2)
@ 2013-01-11 10:53 Zheng Liu
  2013-01-11 10:53 ` [PATCH 1/7 v2] ext4: refine extent status tree Zheng Liu
                   ` (6 more replies)
  0 siblings, 7 replies; 29+ messages in thread
From: Zheng Liu @ 2013-01-11 10:53 UTC (permalink / raw)
  To: linux-ext4; +Cc: Zheng Liu, Jan kara, Theodore Ts'o

Hi all,

Here is my second try to implement the second step of extent status tree in
ext4.  The changelog is as below.

v2 <- v1:
 - drop patches that try to improve unwritten extent conversion
 - remove EXT4_MAP_FROM_CLUSTER flag
 - add tracepoint for ext4_es_lookup_extent()
 - drop a patch, which tries to fix a warning when bigalloc and delalloc are
   enabled
 - add a shrinker to reclaim memory from extent status tree
 - rebase against 3.8-rc2

Now the patch set makes extent status tree to track all extent status in memory
and makes it as a extent cache.

The patches that try to improve unwritten extent conversion are dropped because
Jan has worked on it and has a perfect solution.

Now when bigalloc and delalloc are enabled, there still has some works to be
done.  The key issue is delayed space reservation.  I tried to improve it using
extent status tree, but I don't have a good idea in my mind.  That would be
great if some one could give me some suggestions.  I think this work should be
as a new patch series.  So I drop a patch that is in the first version.

As Jan and Dave advised, fragmented extent tree will causes that status tree
costs too much memory.  So in this patch set a shrinker is defined to reclaim
memory.  When the status tree of an inode is accessed, the inode will be
inserted into the tail of lru list.  It will be dropped as ext4_clear_inode is
called.  When shrinker tries to reclaim some memory, written/unwritten extents
will be freed from status tree.  Delayed extent in the tree shouldn't be
reclaimed because they are used by fiemap, bigalloc, and seek_data/hole.  I am
worry about the lock contention because a lru lock is used to protect lru list.
This lock will be taken by all inodes in this file system.  So I do some
comparisons to measure this overhead.  The result shows that we don't need to
care this problem.

First I use fio to measure iops on a SSD in my desktop.  The config file is as
below:

== config file ==
[global]
ioengine=libaio
iodepth=8
bs=4k
filesize=1G
fallocate=none
size=8G
directory=/mnt/sda1
thread
group_reporting
runtime=600

[jobs]
numjobs=4
rw=randrw
nrfiles=16

== result of iops ==
    read    write
w/  2237    2233
w/o 2225    2227

In addition, I use 'perf lock' to re-run above test case to understand whether
there is a heavy contention, and the result shows that it is OK.

Other changes in this patch set are minor and straightforward.  Please review
it.  Any feedbacks or comments are welcome.

Thanks,
						- Zheng

Zheng Liu (7):
  ext4: refine extent status tree
  ext4: remove EXT4_MAP_FROM_CLUSTER flag
  ext4: add physical block and status member into extent status tree
  ext4: adjust interfaces of extent status tree
  ext4: track all extent status in extent status tree
  ext4: lookup block mapping in extent status tree
  ext4: reclaim extents from extent status tree

 fs/ext4/ext4.h              |  19 +-
 fs/ext4/extents.c           |  44 ++--
 fs/ext4/extents_status.c    | 505 ++++++++++++++++++++++++++++++++------------
 fs/ext4/extents_status.h    |  53 ++++-
 fs/ext4/file.c              |  14 +-
 fs/ext4/inode.c             | 138 +++++++++---
 fs/ext4/super.c             |   6 +
 include/trace/events/ext4.h | 118 ++++++++---
 8 files changed, 652 insertions(+), 245 deletions(-)

-- 
1.7.12.rc2.18.g61b472e


^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2013-01-24 20:03 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-11 10:53 [PATCH 0/7 v2] ext4: extent status tree (step2) Zheng Liu
2013-01-11 10:53 ` [PATCH 1/7 v2] ext4: refine extent status tree Zheng Liu
2013-01-23  4:20   ` Theodore Ts'o
2013-01-11 10:53 ` [PATCH 2/7 v2] ext4: remove EXT4_MAP_FROM_CLUSTER flag Zheng Liu
2013-01-11 10:53 ` [PATCH 3/7 v2] ext4: add physical block and status member into extent status tree Zheng Liu
2013-01-17  4:42   ` Theodore Ts'o
2013-01-18  9:49     ` Zheng Liu
2013-01-11 10:53 ` [PATCH 4/7 v2] ext4: adjust interfaces of " Zheng Liu
2013-01-11 10:53 ` [PATCH 5/7 v2] ext4: track all extent status in " Zheng Liu
2013-01-23  4:31   ` Theodore Ts'o
2013-01-11 10:53 ` [PATCH 6/7 v2] ext4: lookup block mapping " Zheng Liu
2013-01-18  4:00   ` Theodore Ts'o
2013-01-18  9:52     ` Zheng Liu
2013-01-11 10:53 ` [PATCH 7/7 v2] ext4: reclaim extents from " Zheng Liu
2013-01-18  5:19   ` Theodore Ts'o
2013-01-18  5:39     ` Theodore Ts'o
2013-01-21  7:24       ` Zheng Liu
2013-01-21 15:00         ` Theodore Ts'o
2013-01-21 17:09           ` Zheng Liu
2013-01-23  6:06             ` [PATCH] fs: allow for fs-specific objects to be pruned as part of pruning inodes Theodore Ts'o
2013-01-23 10:52               ` Jan Kara
2013-01-23 13:06               ` Carlos Maiolino
2013-01-23 13:32               ` Dave Chinner
2013-01-23 16:34                 ` Theodore Ts'o
2013-01-23 23:35                   ` Dave Chinner
2013-01-24  8:58                 ` Andrew Morton
2013-01-24 20:03                   ` Dave Chinner
2013-01-21 14:43       ` [PATCH 7/7 v2] ext4: reclaim extents from extent status tree Jan Kara
2013-01-21 15:12         ` Zheng Liu

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.