More details about the tmux 2.0 regression

More details about the tmux 2.0 regression

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

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

Re: More details about the tmux 2.0 regression

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

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On Jun  6 12:58, İsmail Dönmez wrote:
> 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.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Jun  8 14:41, Corinna Vinschen wrote:
> On Jun  6 12:58, İsmail Dönmez wrote:
> > 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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More details about the tmux 2.0 regression

[İsmail Dönmez]

On Mon, Jun 8, 2015 at 4:21 PM, Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
> On Jun  8 14:41, Corinna Vinschen wrote:
>> On Jun  6 12:58, İsmail Dönmez wrote:
>> > 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

Re: More details about the tmux 2.0 regression

[İsmail Dönmez]

On Mon, Jun 8, 2015 at 6:12 PM, İsmail Dönmez <ismail@donmez.ws> wrote:
> On Mon, Jun 8, 2015 at 4:21 PM, Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
>> On Jun  8 14:41, Corinna Vinschen wrote:
>>> On Jun  6 12:58, İsmail Dönmez wrote:
>>> > 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

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Jun  8 18:25, İsmail Dönmez wrote:
> On Mon, Jun 8, 2015 at 6:12 PM, İsmail Dönmez <ismail@donmez.ws> wrote:
> > On Mon, Jun 8, 2015 at 4:21 PM, Corinna Vinschen
> > <corinna-cygwin@cygwin.com> wrote:
> >> On Jun  8 14:41, Corinna Vinschen wrote:
> >>> On Jun  6 12:58, İsmail Dönmez wrote:
> >>> > 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!

Thanks for testing.

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More details about the tmux 2.0 regression

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > 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 Cygwin has that covered.


Regards,
Achim

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

On Jun  8 16:10, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > 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.

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Jun  8 19:18, Corinna Vinschen wrote:
> On Jun  8 16:10, Achim Gratz wrote:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > > 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/


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More details about the tmux 2.0 regression

[İsmail Dönmez]

On Mon, Jun 8, 2015 at 11:07 PM, Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
> On Jun  8 19:18, Corinna Vinschen wrote:
>> On Jun  8 16:10, Achim Gratz wrote:
>> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
>> > > > 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

Re: More details about the tmux 2.0 regression

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

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

Regards,
Achim.

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

On Jun  9 08:02, İsmail Dönmez wrote:
> On Mon, Jun 8, 2015 at 11:07 PM, Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> > On Jun  8 19:18, Corinna Vinschen wrote:
> >> On Jun  8 16:10, Achim Gratz wrote:
> >> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> >> > > > 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!

Thanks for testing!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

On Jun  9 06:58, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 
> > > 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.

That requires to update procps and cygwin packages at the same time.
It also replaces a ps using internal functionality with a ps which
uses the /proc emulation layer, which *is* slower.

What about patching Cygwin's ps to add the required functionality?
SHTDI, of course...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: More details about the tmux 2.0 regression

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 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,
Achim.

Re: More details about the tmux 2.0 regression

[Helmut Karlowski]

Achim Gratz
Tue, 9 Jun 2015 11:18:40 +0000 (UTC)
---------------------------------------------------

> 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

Re: More details about the tmux 2.0 regression

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Jun  9 14:23, Helmut Karlowski wrote:
> Achim Gratz
> Tue, 9 Jun 2015 11:18:40 +0000 (UTC)
> ---------------------------------------------------
> 
> > 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.

-W is not possible with procps, unless somebody implements it.  We can't
just copy over the code from Cygwin's ps for licensing reasons either.

But, here's the deal:  Nothing at all speaks against improving Cygwin's
ps to put it on a better footing with procps.

It's rather old code(*), but pretty simple and not much of it (less than
400 lines).  It should be fairly easy to add functionality to make it a
better ps.  A clear case of https://cygwin.com/acronyms/#PGA


Corinna


(*) There are still Windows 2000 considerations in the code.  Yuk!


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]