From: Chen Gang <gang.chen.5i5j@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, anthony@codemonkey.ws
Subject: Re: [Qemu-devel] [PATCH 4/5] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation
Date: Sun, 23 Mar 2014 21:27:29 +0800 [thread overview]
Message-ID: <532EE141.5090906@gmail.com> (raw)
In-Reply-To: <5325A7F0.9000300@gmail.com>
On 03/16/2014 09:32 PM, Chen Gang wrote:
> On 03/08/2014 09:58 PM, Chen Gang wrote:
>> OK, thanks.
>>
>> Next, I will/should continue to analyse the performance issue for 9pfs
>> when users drop into a long directory path under bash shell.
>>
>
> After have a test, I am sure it is not 9pfs issue, either not Qemu's
> issue, it's Linux kernel vfs or block sub-systems' issue. The related
> test environments (originally, our 9pfs is upper on ext4):
>
> - for ext4 file system under my Fedora laptop (Qemu does not start).
>
> - for ntfs file system under my Fedora laptop (Qemu does not start).
>
> - for ext4 file system under my Ubuntu in Qemu.
>
> For a very long file name (e.g. > 3K long), all of them are very very
> slow. (and I also tested the ext2 /boot partition under Ubuntu in Qemu,
> it is not slow, I guess the reson is its partition size is small).
>
>
> Next, I will/shall communicate with upstream kernel for it. :-)
>
>
>> Although I am not quite sure, hope I can find the root cause within
>> month (2014-03-31).
>>
>> Welcome any suggestions, discussions, and completions for it.
>>
>> Thanks.
>>
>
>
Sorry, after give a little more test, for the lower performance issue
under a long deep path, 'bash' is the direct cause (may also be root
cause).
Also sorry, 'bash' is out of my focusing border now, so I provide the
related information below, welcome any members (e.g. 'bash', fedora, or
ubuntu members) to help check, when they have time, thanks.
Environments (e.g. fedora 17):
[root@gchen ~]# uname -a
Linux gchen 3.14.0-rc7-next-20140321 #2 SMP Sun Mar 23 19:46:37 CST 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@gchen ~]# cat /etc/*-release
Fedora release 17 (Beefy Miracle)
NAME=Fedora
VERSION="17 (Beefy Miracle)"
ID=fedora
VERSION_ID=17
PRETTY_NAME="Fedora 17 (Beefy Miracle)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:17"
Fedora release 17 (Beefy Miracle)
Fedora release 17 (Beefy Miracle)
'bash' is very busy under user mode (I am only one cpu):
top - 20:12:01 up 23 min, 5 users, load average: 0.60, 0.35, 0.33
Tasks: 137 total, 2 running, 135 sleeping, 0 stopped, 0 zombie
Cpu(s): 97.1%us, 2.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1942468k total, 820896k used, 1121572k free, 40060k buffers
Swap: 0k total, 0k used, 0k free, 446328k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4010 root 20 0 113m 5236 3096 R 92.3 0.3 3:57.19 -bash
2955 root 20 0 136m 21m 10m S 2.9 1.1 0:16.00 /usr/bin/Xorg :0 -background none -logverbose 7 -auth /var/run/gdm/auth-for-gdm-8
3860 gchen 20 0 582m 28m 19m S 1.9 1.5 0:22.93 gnome-terminal
3348 gchen 20 0 1405m 117m 46m S 1.0 6.2 0:23.34 /usr/bin/gnome-shell
3728 gchen 20 0 442m 8248 6140 S 1.0 0.4 0:12.05 /usr/bin/ibus-daemon -r --xim
...
The related 'bash' stack is below (each time, always drop into it):
#0 0x00000036bb290c1c in strcoll_l () from /lib64/libc.so.6
#1 0x000000000047ff48 in ?? ()
#2 0x0000000000480517 in ?? ()
#3 0x0000000000480fb7 in ?? ()
#4 0x00000000004806e0 in ?? ()
#5 0x0000000000480fb7 in ?? ()
#6 0x00000000004806e0 in ?? ()
#7 0x0000000000482528 in xstrmatch ()
#8 0x0000000000456f79 in binary_test ()
#9 0x000000000042f308 in ?? ()
#10 0x000000000042f449 in ?? ()
#11 0x0000000000432379 in execute_command_internal ()
#12 0x000000000043583e in execute_command ()
#13 0x000000000043295e in execute_command_internal ()
#14 0x000000000043349f in execute_command_internal ()
#15 0x000000000043583e in execute_command ()
#16 0x0000000000433464 in execute_command_internal ()
#17 0x000000000043583e in execute_command ()
#18 0x0000000000433464 in execute_command_internal ()
#19 0x000000000043583e in execute_command ()
#20 0x0000000000433464 in execute_command_internal ()
#21 0x000000000043583e in execute_command ()
#22 0x0000000000433464 in execute_command_internal ()
#23 0x000000000043583e in execute_command ()
#24 0x0000000000433464 in execute_command_internal ()
#25 0x000000000043583e in execute_command ()
#26 0x0000000000433464 in execute_command_internal ()
#27 0x0000000000432613 in execute_command_internal ()
#28 0x000000000043440e in ?? ()
#29 0x0000000000431a8c in ?? ()
#30 0x0000000000432873 in execute_command_internal ()
#31 0x000000000043583e in execute_command ()
#32 0x000000000043310d in execute_command_internal ()
#33 0x000000000043349f in execute_command_internal ()
#34 0x000000000043583e in execute_command ()
#35 0x0000000000433464 in execute_command_internal ()
#36 0x000000000043583e in execute_command ()
#37 0x0000000000433464 in execute_command_internal ()
#38 0x000000000043583e in execute_command ()
#39 0x0000000000433464 in execute_command_internal ()
#40 0x000000000043583e in execute_command ()
#41 0x0000000000433464 in execute_command_internal ()
#42 0x000000000043583e in execute_command ()
#43 0x0000000000433464 in execute_command_internal ()
#44 0x000000000043583e in execute_command ()
#45 0x0000000000433464 in execute_command_internal ()
#46 0x000000000043583e in execute_command ()
#47 0x0000000000433464 in execute_command_internal ()
#48 0x000000000043583e in execute_command ()
#49 0x0000000000433464 in execute_command_internal ()
#50 0x000000000043583e in execute_command ()
#51 0x0000000000433464 in execute_command_internal ()
#52 0x0000000000432613 in execute_command_internal ()
#53 0x000000000043440e in ?? ()
#54 0x00000000004346b5 in execute_shell_function ()
#55 0x00000000004693c7 in gen_compspec_completions ()
#56 0x0000000000469b69 in ?? ()
#57 0x0000000000469cac in programmable_completions ()
#58 0x0000000000463d01 in ?? ()
#59 0x000000000049130f in ?? ()
#60 0x0000000000491d68 in rl_complete_internal ()
#61 0x000000000048978d in _rl_dispatch_subseq ()
#62 0x0000000000489cf8 in readline_internal_char ()
#63 0x000000000048a1a5 in readline ()
#64 0x000000000041e59c in ?? ()
#65 0x0000000000420158 in ?? ()
#66 0x0000000000422d76 in ?? ()
#67 0x000000000042610b in yyparse ()
#68 0x000000000041de6a in parse_command ()
#69 0x000000000041df36 in read_command ()
#70 0x000000000041e193 in reader_loop ()
#71 0x000000000041c6e5 in main ()
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
next prev parent reply other threads:[~2014-03-23 13:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 15:16 [Qemu-devel] [PULL] VirtFS update Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 1/5] fsdev: Fix overrun after readlink() fills buffer completely Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 2/5] hw/9pfs/virtio-9p-local.c: move v9fs_string_free() to below "err_out:" Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 3/5] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 4/5] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation Aneesh Kumar K.V
2014-03-08 13:58 ` Chen Gang
2014-03-16 13:32 ` Chen Gang
2014-03-18 0:31 ` [Qemu-devel] [PATCH trivial] target-arm/gdbstub64.c: remove useless 'break' statement Chen Gang
2014-03-18 0:39 ` Peter Maydell
2014-03-18 0:53 ` Chen Gang
2014-03-18 5:14 ` Peter Crosthwaite
2014-03-19 3:25 ` Chen Gang
2014-03-23 13:27 ` Chen Gang [this message]
2014-03-07 15:16 ` [Qemu-devel] [PATCH 5/5] hw/9pfs: Include virtio-9p-device.o in build Aneesh Kumar K.V
2014-03-07 15:30 ` Andreas Färber
2014-03-07 17:07 ` Aneesh Kumar K.V
2014-03-08 12:52 ` [Qemu-devel] [PULL] VirtFS update Peter Maydell
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=532EE141.5090906@gmail.com \
--to=gang.chen.5i5j@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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).