Discussion:
More details about the tmux 2.0 regression
(too old to reply)
İsmail Dönmez
2015-06-06 09:58:29 UTC
Permalink
Hi,

I had a nice discussion with tmux maintainers over at
https://github.com/tmux/tmux/issues/13 about the tmux 2.0 regression
on Cygwin.

Long story short, tmux is trying to read /proc/<pid>/cmdline and
/proc/<pid>/cwd for various reasons and for non-Cygwin programs this
is quite slow. You can reproduce this easily run cmd.exe inside bash
and try to

cat /proc/<pid of cmd.exe>/cmdline

and see it takes a second long to print "<defunct>". Would be nice to
fix this slowdown so tmux can be speedy again. For now setting
automatic-rename to off

set -g automatic-rename off

helps somewhat.

Regards,
ismail

--
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
İsmail Dönmez
2015-06-06 10:02:11 UTC
Permalink
Post by İsmail Dönmez
set -g automatic-rename off
Should be setw -g ...

Also if there is an api to detect if a process is non-cygwin that
would also help on tmux side.

--
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
İsmail Dönmez
2015-06-08 15:12:56 UTC
Permalink
On Mon, Jun 8, 2015 at 4:21 PM, Corinna Vinschen
Post by İsmail Dönmez
Hi,
I had a nice discussion with tmux maintainers over at
https://github.com/tmux/tmux/issues/13 about the tmux 2.0 regression
on Cygwin.
Long story short, tmux is trying to read /proc/<pid>/cmdline and
/proc/<pid>/cwd for various reasons and for non-Cygwin programs this
is quite slow. You can reproduce this easily run cmd.exe inside bash
and try to
cat /proc/<pid of cmd.exe>/cmdline
Good catch!
The problem here was that this functionality is very Cygwin centric. It
tries to call into the process itself to fetch the information.
E.g, assuming you have some /proc/1234, it tries to fetch the information
by sending a request to process 1234 and then waits for that process
setting a semaphore. A non-Cygwin process will obviously fail to do so,
not knowing about the method at all.
I fixed that in the Cygwin git repo and it seems to work much better now
to run native tools inside tmux with this change.
I'll upload a developer snapshot on https://cygwin.com/snapshots/ later
today.
Snapshot is up.
That resolves the problem for me, cheers!

--
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
İsmail Dönmez
2015-06-08 15:25:59 UTC
Permalink
Post by İsmail Dönmez
On Mon, Jun 8, 2015 at 4:21 PM, Corinna Vinschen
Post by İsmail Dönmez
Hi,
I had a nice discussion with tmux maintainers over at
https://github.com/tmux/tmux/issues/13 about the tmux 2.0 regression
on Cygwin.
Long story short, tmux is trying to read /proc/<pid>/cmdline and
/proc/<pid>/cwd for various reasons and for non-Cygwin programs this
is quite slow. You can reproduce this easily run cmd.exe inside bash
and try to
cat /proc/<pid of cmd.exe>/cmdline
Good catch!
The problem here was that this functionality is very Cygwin centric. It
tries to call into the process itself to fetch the information.
E.g, assuming you have some /proc/1234, it tries to fetch the information
by sending a request to process 1234 and then waits for that process
setting a semaphore. A non-Cygwin process will obviously fail to do so,
not knowing about the method at all.
I fixed that in the Cygwin git repo and it seems to work much better now
to run native tools inside tmux with this change.
I'll upload a developer snapshot on https://cygwin.com/snapshots/ later
today.
Snapshot is up.
That resolves the problem for me, cheers!
One question though, would it be possible to return executable name
instead of <defunct> for non-Cygwin processes?

--
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
Achim Gratz
2015-06-08 16:10:20 UTC
Permalink
Post by İsmail Dönmez
One question though, would it be possible to return executable name
instead of <defunct> for non-Cygwin processes?
That should work, it just needs implementing.
However, I'm just mulling over another idea. It's probably even
possible to return the comand line and cwd, as long as the calling
process (cat) has permission to open a handle to the requested process.
I'll toy around with this a bit...
Does that mean that top would finally be able to show Windows processes as well?

On another front, I've recently uüstreamed a patch for a Perl distribution
to use /proc/pid/statm because ps from Cygwin doesn't implement a switch to
show the vmsize information. The maintainer of said distribution said he
was expecting a BSD ps before anything else and didn't like the Linux /proc
interface a lot, but it seems we might want to move to a more modern ps
implementation (Linux ps uses /proc under the hood, AFAIK) when the
underlying functionality in
İsmail Dönmez
2015-06-09 05:02:47 UTC
Permalink
On Mon, Jun 8, 2015 at 11:07 PM, Corinna Vinschen
Post by Achim Gratz
Post by İsmail Dönmez
One question though, would it be possible to return executable name
instead of <defunct> for non-Cygwin processes?
That should work, it just needs implementing.
However, I'm just mulling over another idea. It's probably even
possible to return the comand line and cwd, as long as the calling
process (cat) has permission to open a handle to the requested process.
I'll toy around with this a bit...
Does that mean that top would finally be able to show Windows processes as well?
Looks like it. My patch seems to work nicely, it just needs some polish.
I uploaded a new developer snapshot which implements this.
Please give it a try: https://cygwin.com/snapshots/
Seems to work here, cheers!

--
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
Achim Gratz
2015-06-09 06:58:27 UTC
Permalink
Post by Achim Gratz
On another front, I've recently uüstreamed a patch for a Perl distribution
to use /proc/pid/statm because ps from Cygwin doesn't implement a switch to
show the vmsize information. The maintainer of said distribution said he
was expecting a BSD ps before anything else and didn't like the Linux /proc
interface a lot, but it seems we might want to move to a more modern ps
implementation (Linux ps uses /proc under the hood, AFAIK) when the
underlying functionality in Cygwin has that covered.
Use procps?
Jettison ps and move procps into Base? It looks like it wouldn't pull in
any new dependencies beyond libncursesw.

Rega
Achim Gratz
2015-06-09 11:18:40 UTC
Permalink
That requires to update procps and cygwin packages at the same time.
I thought the raison d'être was that procps, by using the /proc interface,
would not be intertwined with the kernel anymore... I didn't suggest to move
it into another package, btw: the procps package should just be in the Base
group to ensure it is in all installs.
It also replaces a ps using internal functionality with a ps which
uses the /proc emulation layer, which *is* slower.
I can't think of a problem created by that fact (which doesn't mean that
none exist).
What about patching Cygwin's ps to add the required functionality?
SHTDI, of course...
Again, I just think procps is good enough for us as is, it is good enough
for Linux anyway.
:-)


Regards,
Ac
Helmut Karlowski
2015-06-09 12:23:57 UTC
Permalink
Achim Gratz
Tue, 9 Jun 2015 11:18:40 +0000 (UTC)
---------------------------------------------------
Post by Achim Gratz
Again, I just think procps is good enough for us as is, it is good enough
for Linux anyway.
:-)
Would be great if the ps from procps would work as the current ps,
e.g. ps -W (with and without windows-processes - is this possible
now?), and no slowdown.

-Helmut



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

Continue reading on narkive:
Loading...