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 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.