Hi Coly, Forgive me for hijacking your thread. I cannot comment on the cleanup, as I am new to mballoc code, but I was wondering if you could offer me a piece of advise. In the current implementation (prototype) of ext4 snapshots, I have an outstanding circular lockdep warning to fix: inode->i_data_sem => grp->alloc_sem => snapshot->i_data_sem/1 => grp->alloc_sem Snapshot block allocation can be nested inside another inode block allocation, because COW of bitmap block is triggered on get_write_access() inside ext4_mb_mark_diskspace_used(). i_data_sem nested lockdep is handled by calling down_read/write_nested() in ext4_map_blocks(): https://github.com/amir73il/ext4-snapshots/blob/ext4-snapshots/fs/ext4/inode.c#L1540 In ext3/next3, handling nested i_truncate_mutex lockdep was enough, but in ext4, I need to take care of alloc_sem and lg_mutex as well. I "handled" lg_mutex by never setting EXT4_MB_HINT_DATA on snapshot files. When looking at alloc_sem, I realized that it is only needed to avoid race with adjacent group buddy initialization. Snapshots feature, however, requires that block_size == page_size, so it seems that alloc_sem can be avoided altogether. My questions are: 1. Am I missing something in my analysis? 2. Wouldn't it make sense to bypass alloc_sem at all times if block_size == page_size (or block_size*2 >= page_size), regardless of the snapshots feature? After all, a group buddy is always initialized before calling allocation routines. Thanks for your time, Amir. On Sun, Feb 6, 2011 at 6:53 AM, Coly Li <i@xxxxxxx> wrote: > This patch set contains several trivial code cleanup to mballoc code. > A basic testing is done with Linux 2.6.38-rc3+ (commit 44f2c5c8). > > Signed-off-by: Coly Li <bosong.ly@xxxxxxxxxx> > Cc: Alex Tomas <alex@xxxxxxxxxxxxx> > Cc: Theodore Tso <tytso@xxxxxxxxxx> > --- > fs/ext4/mballoc.c | 15 ++++++++++----- > fs/ext4/mballoc.h | 2 +- > 2 files changed, 11 insertions(+), 6 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
