qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

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