public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Machida, Hiroyuki" <machida@sm.sony.co.jp>
To: linux-kernel@vger.kernel.org, hirofumi@mail.parknet.co.jp
Subject: [RFC][FAT] diren scan profiling report
Date: Tue, 30 Aug 2005 12:01:03 +0900	[thread overview]
Message-ID: <4313CBEF.9020505@sm.sony.co.jp> (raw)



As I said in "[RFC] FAT dirent scan with hint"
	<43024977.7020101@sm.sony.co.jp>, we realized that FAT/VFAT has
poor performance with scanning directory entries.

Per discussions with Ogawa-san, VFAT maintainer, I took profiling data
to seek better solution. Here are results attached.

In short, I would say we need to reduce following factors.
	a) number of iterations inside fat_search_long()
	b) number of callings to uni16_to_x8()
	c) number of callings to fat__get_entry(), for short name scan.

In another E-mail, I'll send revised version patch which use hint
values to scan dirent. That patch would reduce number of iterations
inside fat_search_long() and fat_scan(). Those contributes reductions
above a)-c) factors.


RESULTS:


1-1) Top 10 function consuming time on long file name dir scan
(vfat_lookup) for 4095th LFN entry.

% kd -n 10 /tmp/lfn_kft-a.log
Function                            Count Time     Average  Local
----------------------------------- ----- -------- -------- --------
vfat_lookup                             1  1242285  1242285      705
vfat_find                               1  1241522  1241522      629
fat_search_long                         1  1240893  1240893   887490
uni16_to_x8                          4209   250222       59   249143
fat_get_entry                         765    69908       91     3306
fat__get_entry                        762    66602       87    50796
fat_shortname2uni                     593    33158       55    11393
fat_short2lower_uni                   414    21765       52    20860
fat_bmap                              202    13425       66      857
fat_bmap_cluster                      201    12568       62     1015

  *)To exclude profiling overhead, doesn't count functions < 50usec
  **) Remove "inline" from fat/dir.c to count up inline funcs.

1-2) Top 10 function consuming time on short file name dir scan
(fat_scan) for 4095th short file name entry.

% kd -n 10 /tmp/kft-a.log
Function                            Count Time     Average  Local
----------------------------------- ----- -------- -------- --------
fat_scan                                1   149743   149743    68069
fat_get_short_entry                   812    81512      100    11706
fat_get_entry                         765    69806       91     3252
fat__get_entry                        762    66554       87    50425
fat_bmap                              199    13181       66      838
fat_bmap_cluster                      198    12343       62     1055
fat_get_cluster                       194    11288       58     8481
fat_ent_read                           52     2807       53     2583
__getblk                               32     2339       73      326
__bread                                29     2145       73      598

  *)To exclude profiling overhead, doesn't count functions < 50usec
  **) Remove "inline" from fat/dir.c to count up inline funcs.


2-1) how to get result 1-1)

% ( cat <<__CONF
new
begin
        trigger start entry 0xc00cd904  # vfat_lookup
        trigger stop exit 0xc00cd904    # vfat_lookup
        filter mintime 50
        filter maxtime 0
        filter noints
        logentries      5000000
end

__CONF
)  > /proc/kft

% echo prime > /proc/kft

# mount vtat

% time stat 4095th-shortfilename-entry

real    0m1.351s
user    0m0.007s
sys     0m1.295s

# umount

# get data from /proc/kft_data


2-2) how to get result 1-2)


% ( cat <<__CONF
new
begin
        trigger start entry 0xc00c36dc # fat_scan
        trigger stop exit 0xc00c36dc # fat_scan
        filter mintime 50
        filter maxtime 0
        filter noints
        logentries      5000000
end
__CONF
)  > /proc/kft

% echo prime > /proc/kft

# mount msdos

% time stat 4095th-shortname-entry

real    0m0.216s
user    0m0.002s
sys     0m0.200s


# umount

# get data from /proc/kft_data


-- 
Hiroyuki Machida		machida@sm.sony.co.jp		
SSW Dept. HENC, Sony Corp.

             reply	other threads:[~2005-08-30  3:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30  3:01 Machida, Hiroyuki [this message]
2005-08-30  4:50 ` [PATCH][FAT] FAT dirent scan with hin take #2 Machida, Hiroyuki
2005-08-30  8:51   ` Pekka Enberg
2005-08-30  8:55   ` Pekka Enberg
2005-08-30  9:18     ` Vojtech Pavlik
2005-08-30 19:27   ` OGAWA Hirofumi
2005-08-31  1:43     ` OGAWA Hirofumi
2005-08-31  8:25     ` [PATCH][FAT] FAT dirent scan with hin take #3 Machida, Hiroyuki
2005-08-31 10:00       ` Pekka Enberg
2005-08-31 12:57         ` Machida, Hiroyuki
2005-08-31 13:51           ` Pekka Enberg
2005-08-31 13:53             ` Pekka Enberg
2005-08-31 10:03       ` Pekka Enberg
2005-08-31 13:27         ` Machida, Hiroyuki
2005-08-31 10:14       ` Pekka Enberg
2005-08-31 13:04         ` Machida, Hiroyuki
2005-08-31 13:52           ` Pekka Enberg
2005-08-31 16:41       ` OGAWA Hirofumi
2005-09-01  5:50         ` Machida, Hiroyuki
2005-09-01  7:45           ` Machida, Hiroyuki
2005-09-01 17:48           ` OGAWA Hirofumi
2005-09-14 18:59             ` Machida, Hiroyuki

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=4313CBEF.9020505@sm.sony.co.jp \
    --to=machida@sm.sony.co.jp \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox