headers
Magnus Holmgren | 1 Sep 2010 20:16
Picon

[PATCH] Faster process initialization

This patch speeds up process initialization on 64-bit systems. Maybe
the comment "Initialize signal processing here ..." should be re-worded
or removed completely.

The speed difference can be noticeable.
"while (true); do date; done | uniq -c" manages more than 3 times more
"date" executions per second on my system.

2010-09-01  Magnus Holmgren  <magnushol <at> gmail.com>

	* dcrt0.cc (dll_crt0_0): Remove call to sigproc_init. It creates
	a thread, and execution of that thread can be delayed during
	DLL init, slowing things down (seen on 64-bit systems).
	(dll_crt0_1): Always call sigproc_init.

Index: src/winsup/cygwin/dcrt0.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.382
diff -u -p -r1.382 dcrt0.cc
--- src/winsup/cygwin/dcrt0.cc  30 Aug 2010 23:23:28 -0000      1.382
+++ src/winsup/cygwin/dcrt0.cc  1 Sep 2010 17:49:26 -0000
 <at>  <at>  -740,11 +740,9  <at>  <at>  dll_crt0_0 ()
         }
      }

-  /* Initialize signal processing here, early, in the hopes that the creation
-     of a thread early in the process will cause more predictability in memory
-     layout for the main thread. */
-  if (!dynamically_loaded)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Holmgren | 1 Sep 2010 20:18
Picon

[PATCH] Faster process initialization

This patch speeds up process initialization on 64-bit systems. Maybe
the comment "Initialize signal processing here ..." should be re-worded
or removed completely.

The speed difference can be noticeable.
"while (true); do date; done | uniq -c" manages more than 3 times more
"date" executions per second on my system.

2010-09-01  Magnus Holmgren  <magnushol <at> gmail.com>

	* dcrt0.cc (dll_crt0_0): Remove call to sigproc_init. It creates
	a thread, and execution of that thread can be delayed during
	DLL init, slowing things down (seen on 64-bit systems).
	(dll_crt0_1): Always call sigproc_init.

Index: src/winsup/cygwin/dcrt0.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.382
diff -u -p -r1.382 dcrt0.cc
--- src/winsup/cygwin/dcrt0.cc  30 Aug 2010 23:23:28 -0000      1.382
+++ src/winsup/cygwin/dcrt0.cc  1 Sep 2010 17:49:26 -0000
 <at>  <at>  -740,11 +740,9  <at>  <at>  dll_crt0_0 ()
         }
      }

-  /* Initialize signal processing here, early, in the hopes that the creation
-     of a thread early in the process will cause more predictability in memory
-     layout for the main thread. */
-  if (!dynamically_loaded)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Faylor | 1 Sep 2010 20:35
Favicon

Re: [PATCH] Faster process initialization

On Wed, Sep 01, 2010 at 08:16:49PM +0200, Magnus Holmgren wrote:
>This patch speeds up process initialization on 64-bit systems. Maybe
>the comment "Initialize signal processing here ..." should be re-worded
>or removed completely.

Yes, the fact that the comment makes no sense when moved would be your
first clue that it should be deleted.

>The speed difference can be noticeable.
>"while (true); do date; done | uniq -c" manages more than 3 times more
>"date" executions per second on my system.

Although you participated in the thread, you apparently ignored this:

http://cygwin.com/ml/cygwin/2010-08/msg01000.html

So, patch thoughtfully rejected.

cgf
Permalink | Reply | 0 comments |
headers
Yoni Londner | 6 Sep 2010 11:52
Picon

Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance

Hi,

Abstract: I prepared a patch that improves Cygwin Filesystem performance 
by x4 on Cygwin 1.7.5 (1.7.5 vanilla 530ms --> 1.7.5 patched 120ms). I 
ported the patch to 1.7.7, did tests, and found out that 1.7.7 had a 
very serious 9x (!) performance degradation from 1.7.5 (1.7.5 vanilla 
530ms --> 1.7.7 vanilla 3900ms --> 1.7.7 patched 3500ms), which does 
makes this patch useless until the performance degradation is fixed.

=======================================================================
My patch:
------------

As a cygwin user, I wanted to make cygwin faster, since Cygwin is my 
host for Win32 Windows development platform (make, cvs, grep etc).

I saw that simple file access operations were x10 to x50 times slower 
than on Windows.
And x10 to x50 slower than VMWare linux accessing the drive using HostFS 
(which allows Linux VM to access the Windows C: drive).

So I did some performace test on Cygwin 1.7.5, and found out the biggest 
bottleneck were:

- CreateFile()/CloseHandle() on syscalls that only need file node info 
retrival, not file contents retrival (such as stat()). This can be 
solved by calling Win32 that do not open the File handle itself, rather 
query by name, or opening the directory handle (which is MUCH faster).

- repetitive Win32 Kernel calls on a single syscall (stat() would call
(Continue reading)

Permalink | Reply | 22 comments |
headers
Corinna Vinschen | 6 Sep 2010 15:24
Favicon

Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance

Hi Yoni,

On Sep  6 12:52, Yoni Londner wrote:
> Hi,
> 
> Abstract: I prepared a patch that improves Cygwin Filesystem
> performance by x4 on Cygwin 1.7.5 (1.7.5 vanilla 530ms --> 1.7.5
> patched 120ms). I ported the patch to 1.7.7, did tests, and found
> out that 1.7.7 had a very serious 9x (!) performance degradation
> from 1.7.5 (1.7.5 vanilla 530ms --> 1.7.7 vanilla 3900ms --> 1.7.7
> patched 3500ms), which does makes this patch useless until the
> performance degradation is fixed.

The problem is, I can't reproduce such a degradation.  If I run sometimg
like `time ls -l /bin > /dev/null', the times are very slightly better
with 1.7.7 than with 1.7.5 (without caching effect 1200ms vs. 1500ms,
with caching effect 500ms vs. 620ms on average).  Starting with 1.7.6,
Cygwin reused handles from symlink_info::check in stat() and other
syscalls.  If there is such degradation under some circumstances, I need
a reproducible scenario, or at least some strace output which shows at
which point this happens.  Apart from actual patches this should be
discussed on the cygwin-developer list.

> =======================================================================
> My patch:
> ------------

First of all, your patch is very certainly significant in terms of code
size.  If you want to contribute code from it, we need a signed copyright
assignment from you.  See http://cygwin.com/contrib.html, the "Before you
(Continue reading)

Permalink | Reply | 21 comments |
headers
Christopher Faylor | 6 Sep 2010 17:25
Favicon

Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance

Thanks for the patch and for all of the work you put into it.

On Mon, Sep 06, 2010 at 03:24:09PM +0200, Corinna Vinschen wrote:
>The patch is also missing a ChangeLog entry.  I only took a quick glance
>over the patch itself.  The code doesn't look correctly formatted in GNU
>style.  Also, using the diff -up flags would be helpful.

And, this is the type of patch which would be better served if submitted
in small chunks.  You have multiple changes in your 1158 line patch and
they don't seem to all be interrelated.

Also, in addition to formatting concerns, you don't seem to have used
comments very much.  Corinna and I have been making a concerted effort
to comment changes more thoroughly so it would be nice if your patch
contained more of those.

I didn't look at the patch very closely either since there are copyright
issues but some of your conclusions don't seem right to me.  I agree
with Corinna's response.

cgf
Permalink | Reply | 0 comments |
headers
Earl Chew | 9 Sep 2010 00:27
Favicon

Mounting /tmp at TMP or TEMP as a last resort

We have an installation that we deploy to a bunch of workstations. We prefer
if the installation uses the temporary file directory that Windows has already
allocated for the user.

The entry for /tmp in /etc/fstab, or the directory /tmp, is preferred.
If neither is found, the patch mounts /tmp at the directory indicated
by the environment variable TMP or, if that is not set, TEMP. The patch
does nothing if neither environment variable is set.

Earl

--- mount.h.orig	2010-03-18 07:57:09.000000000 -0700
+++ mount.h	2010-09-08 11:10:23.218802900 -0700
 <at>  <at>  -140,6 +140,7  <at>  <at> 
   int nmounts;
   mount_item mount[MAX_MOUNTS];

+  static bool got_tmp;
   static bool got_usr_bin;
   static bool got_usr_lib;
   static int root_idx;
--- mount.cc.orig	2010-03-30 03:03:09.000000000 -0700
+++ mount.cc	2010-09-08 11:35:27.765251900 -0700
 <at>  <at>  -45,6 +45,7  <at>  <at> 
 #define isproc(path) \
   (path_prefix_p (proc, (path), proc_len, false))

+bool NO_COPY mount_info::got_tmp;
 bool NO_COPY mount_info::got_usr_bin;
 bool NO_COPY mount_info::got_usr_lib;
(Continue reading)

Permalink | Reply | 10 comments |
headers
Christopher Faylor | 9 Sep 2010 00:41
Favicon

Re: Mounting /tmp at TMP or TEMP as a last resort

On Wed, Sep 08, 2010 at 03:27:14PM -0700, Earl Chew wrote:
>We have an installation that we deploy to a bunch of workstations. We prefer
>if the installation uses the temporary file directory that Windows has already
>allocated for the user.
>
>The entry for /tmp in /etc/fstab, or the directory /tmp, is preferred.
>If neither is found, the patch mounts /tmp at the directory indicated
>by the environment variable TMP or, if that is not set, TEMP. The patch
>does nothing if neither environment variable is set.

Thanks for the patch but I don't think this is generally useful.  If you
need to mount /tmp somewhere else then it should be fairly trivial to
automatically update /etc/fstab.  Corinna may disagree, but I think we
should keep the parsing of /etc/fstab as lean as possible; particularly
when there are alternatives to modifying Cygwin to achieve the desired
result.

cgf
Permalink | Reply | 9 comments |
headers
Earl Chew | 9 Sep 2010 00:59
Favicon

Re: Mounting /tmp at TMP or TEMP as a last resort

On 08/09/2010 3:41 PM, Christopher Faylor wrote:
> Thanks for the patch but I don't think this is generally useful.  If you
> need to mount /tmp somewhere else then it should be fairly trivial to
> automatically update /etc/fstab.  Corinna may disagree, but I think we
> should keep the parsing of /etc/fstab as lean as possible; particularly
> when there are alternatives to modifying Cygwin to achieve the desired
> result.

Yes, I understand what you're saying.

In our situation, we prefer an out-of-the-box deployment. (We're
essentially trying to get to a "untar this and use it" state).

That said, I don't think it's possible for /etc/fstab to inspect
environment variables, so manipulation of /etc/fstab would
require the assistance of some other script to edit /etc/fstab on
the fly --- and even then it would be difficult to track changes
to the environment variables.

Thanks for the quick feedback.

Earl
Permalink | Reply | 2 comments |
headers
Corinna Vinschen | 9 Sep 2010 09:50
Favicon

Re: Mounting /tmp at TMP or TEMP as a last resort

On Sep  8 15:59, Earl Chew wrote:
> On 08/09/2010 3:41 PM, Christopher Faylor wrote:
> > Thanks for the patch but I don't think this is generally useful.  If you
> > need to mount /tmp somewhere else then it should be fairly trivial to
> > automatically update /etc/fstab.  Corinna may disagree, but I think we
> > should keep the parsing of /etc/fstab as lean as possible; particularly
> > when there are alternatives to modifying Cygwin to achieve the desired
> > result.
> 
> Yes, I understand what you're saying.
> 
> In our situation, we prefer an out-of-the-box deployment. (We're
> essentially trying to get to a "untar this and use it" state).
> 
> That said, I don't think it's possible for /etc/fstab to inspect
> environment variables, so manipulation of /etc/fstab would
> require the assistance of some other script to edit /etc/fstab on
> the fly --- and even then it would be difficult to track changes
> to the environment variables.

Apart from changing /etc/fstab or /etc/fstab.d/$USER by some installer
script, why not just add a one-liner profile script along the lines of

 /etc/profile.d/tmp-mnt.sh:

   mount -f `cygpath -m "${TEMP}"` /tmp

Corinna

--

--
(Continue reading)

Permalink | Reply | 1 comment |

Gmane