linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Namjae Jeon <namjae.jeon@samsung.com>
Subject: Re: [PATCH v3 0/7] f2fs: add tracepoints support in f2fs filesystem
Date: Tue, 09 Apr 2013 21:07:11 +0900	[thread overview]
Message-ID: <1365509231.4353.100.camel@kjgkr> (raw)
In-Reply-To: <CAKYAXd-xpJW=W8UHA=3+Jm-x5y81e__QsLJ0pw4H80SuS+SYSg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]

2013-04-09 (화), 10:04 +0900, Namjae Jeon:
> 2013/4/9, Steven Rostedt <rostedt@goodmis.org>:
> > On Sat, 2013-04-06 at 14:45 +0900, Namjae Jeon wrote:
> >> From: Namjae Jeon <namjae.jeon@samsung.com>
> >>
> >> Add tracepoints in f2fs filesystem for tracing the filesystem
> >> operations for information/debugging purpose if needed. All the
> >> tracepoints are clubbed with respect to functionalities.
> >>
> >> Change Log:
> >> v3: Introduced TRACE_EVENT_CONDITION() macro for checking the
> >> condition page->mapping inside the trace point function call as
> >> per Steve's review comment for the patch
> >>
> >> v2: Added DECLARE_EVENT_CLASS() macro for combining the similar
> >> type of trace function calls which has same type of arguments.
> >>
> >> v1: Introduced the tracepoint functions in f2fs filesystem.
> >>
> >> Namjae Jeon (7):
> >>   f2fs: add tracepoints for sync & Inode operations
> >>   f2fs: add tracepoints for truncate operation
> >>   f2fs: add tracepoint for tracing the page i/o operations
> >>   f2fs: add tracepoints for GC threads
> >>   f2fs: add tracepoints to debug the block allocation & fallocate
> >>   f2fs: add tracepoints for write page operations
> >>   f2fs: add tracepoints to debug checkpoint request
> >>
> >
> Hi. Steve.
> > I have nothing more to add about the tracepoint processing. Looks good.
> > Now if the tracepoints give you sufficient data? That's up to the
> > maintainers to decide.
> Until now, yes. but I will continously try to update trace point more
> if finding additional  needed points after.
> Thanks for review and your ack.

Thank you, Steve. :)

To Namjae,
I've reviewed the patch-set in terms of more informative tracepoints,
and summarized what I'd like to suggest.
Could you examine the following tracepoints?
I really appreciate your job.
Thanks,

*format*
tracepoint [its location] (information)

1. patch 1/7: 

f2fs_sync_file_enter [enter]
(dev,ino,parent,i_mode,i_nlink,i_blocks,fi->i_advise,fi->i_pino,datasync)
f2fs_sync_file_exit [exit] (dev,ino,need_cp,ret)
f2fs_sync_fs [enter] (dev,sbi->s_dirty,wait)
f2fs_iget_enter [enter] (dev,ino)
f2fs_iget_exit [exit] (dev,ino,ret)
f2fs_evict_inode [enter] (dev,ino,i_nlink,i_blocks)
f2fs_unlink_enter [enter]
(dev,ino,i_blocks,dentry->d_name,parent->i_ino)
f2fs_unlink_exit [exit] (dev,ino,ret)

2. patch 2/7:
truncate_blocks_enter [enter] (dev,ino,from)
truncate_blocks_exit [exit] (dev,ino, err)
truncate_inode_blocks_enter [enter] (dev,ino,from)
truncate_inode_blocks_exit [exit] (dev,ino,err)
truncate_partial_nodes [exit] (dev,ino,nid[0],nid[1],nid[2],depth,err)
truncate_data_blocks_range [exit]
(dev,ino,dn->nid,dn->ofs_in_node,nr_free)
truncate_node [exit] (dev,ino,dn->nid,ni.blk_addr)

3. patch 3/7:
get_data_block_ro [all_exits]
(dev,ino,iblock,bh_result->b_blocknr,bh_result->b_size,err)
f2fs_readpage [enter] (dev,ino,index,blk_addr,type)

4. patch 4/7:
get_victim_by_default [exit]
(dev,gc_type,type,p.alloc_mode,p.gc_mode,p.ofs_unit,p.min_segno,sbi->cur_victim_sec)

5. patch 5/7:
f2fs_fallocate [exit] (dev,ino,offset,len,mode,i_blocks,i_size,ret)
f2fs_reserve_new_block [ext] (dev,ino,dn->nid,dn->ofs_in_node)

6. patch 6/7:
submit_write_page [exit] (dev,ino,index,blk_addr,type)
do_submit_bio [if(sbi->bio[btype]]
(dev,btype,sync,bio->bi_sector,bio->bi_size)
f2fs_write_begin [enter] (dev,ino,pos,len,flags)

7. patch 7/7:
write_checkpoint_before_blockop [before block_operations()]
(dev,is_mount,"try to block operations")
write_checkpoint_after_blockop [after block_operations()]
(dev,is_mount,"done block operations")
write_checkpoint_exit [exit] (dev,is_mount,"done checkpoint")

> 
> >
> > Acked-by: Steven Rostedt <rostedt@goodmis.org>
> >
> > -- Steve
> >
> >
> >

-- 
Jaegeuk Kim
Samsung

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-04-09 12:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-06  5:45 [PATCH v3 0/7] f2fs: add tracepoints support in f2fs filesystem Namjae Jeon
2013-04-09  0:25 ` Steven Rostedt
2013-04-09  1:04   ` Namjae Jeon
2013-04-09 12:07     ` Jaegeuk Kim [this message]
2013-04-09 13:07       ` Namjae Jeon

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=1365509231.4353.100.camel@kjgkr \
    --to=jaegeuk.kim@samsung.com \
    --cc=linkinjeon@gmail.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namjae.jeon@samsung.com \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).