From: Daniel Santos <daniel.santos@pobox.com>
To: cygwin@cygwin.com
Subject: Re: long I/O delays when strace is running
Date: Fri, 21 Apr 2017 18:23:00 -0000 [thread overview]
Message-ID: <7d56e728-32a3-9179-b002-e83880e297d0@pobox.com> (raw)
In-Reply-To: <58F9D314.2000100@maxrnd.com>
On 04/21/2017 04:38 AM, Mark Geisert wrote:
>
> I can reproduce your issue on a real Win7.64 machine so that removes
> any possible virtual machine root cause. I was running 'top -s1' in
> one window while running your testcase in another window. Yes, top
> froze for many seconds at a time, then caught its display up, only to
> freeze again repeatedly. It was still frozen for a while after your
> testcase had ended (!), then caught up. Your mention of pinfo::init
> and 'ps' along with my usage of 'top' leads me to think this may be
> somehow related to the /proc filesystem.
>
> Here's my humble contribution to the discussion:
>
> ~ time w
> 02:15:52 up 3 days, 20:34, 0 users, load average: 0.99, 0.62, 0.31
> USER TTY LOGIN@ IDLE JCPU PCPU WHAT
>
> real 0m0.203s <-- OK, nice and fast
> user 0m0.077s
> sys 0m0.139s
>
> ~ time strace -o w.out w
> 02:16:23 up 3 days, 20:34, 0 users, load average: 0.54, 0.55, 0.29
> USER TTY LOGIN@ IDLE JCPU PCPU WHAT
>
> real 0m28.487s <-- but stracing it is much, much slower
> user 0m0.015s
> sys 0m0.000s
>
> The 'w' command is normally pretty fast. Running it under strace
> makes it take an unreasonably long time. Something seems busted
> somewhere. The strace output for this example has many occurrences of
> ~3.1-second delays that seem to occur as w is accumulating process
> time information for all processes.
>
> ..mark
Thanks for the help Mark. My current suspicion is that the _pinfo isn't
getting initialized when the process is exec-ed by strace, but I haven't
proved that. I added a dump() member function to _pinfo, but it crashes
and I can't seem to debug that in gdb (it makes a stacktrace file
instead of letting me debug). So the cygpid.<n> shared object is there,
but I'm suspecting that it's either all zeros or just not fully
initialized -- and this is for the pid of the strace process. So for
each strace process, there's a 2-3 second delay when trying to read the
process list.
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2017-04-21 12:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 18:13 Daniel Santos
2017-04-21 0:11 ` Gluszczak, Glenn
2017-04-21 7:57 ` Daniel Santos
2017-04-21 9:38 ` Daniel Santos
2017-04-21 11:06 ` Daniel Santos
2017-04-21 12:08 ` Mark Geisert
2017-04-21 18:23 ` Daniel Santos [this message]
2017-04-22 15:24 ` Mark Geisert
2017-04-23 12:58 ` Daniel Santos
2017-04-23 18:15 ` Mark Geisert
2017-04-24 8:23 ` Daniel Santos
2017-04-24 9:24 ` Daniel Santos
2017-04-24 9:34 ` Mark Geisert
2017-04-24 15:00 ` Daniel Santos
2017-04-24 19:30 ` Daniel Santos
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=7d56e728-32a3-9179-b002-e83880e297d0@pobox.com \
--to=daniel.santos@pobox.com \
--cc=cygwin@cygwin.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).