Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Subject: Re: nice really nice?
From: Robert Collins <rbcollins AT cygwin DOT com>
To: thomas <cygwin AT cygwin DOT com>
In-Reply-To: <1631951078.20021126142555@huno.net>
References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20021125185701 DOT 02a73ea8 AT pop3 DOT cris DOT com>
	<1038276393 DOT 23528 DOT 366 DOT camel AT lifelesswks> 
	<1022481421 DOT 20021126111535 AT huno DOT net>
	<1038307508 DOT 23528 DOT 397 DOT camel AT lifelesswks> 
	<1631951078 DOT 20021126142555 AT huno DOT net>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-VI9dn+1RUyQsGo/QdWzj"
Date: 27 Nov 2002 07:38:18 +1100
Message-Id: <1038343099.25127.448.camel@lifelesswks>
Mime-Version: 1.0

--=-VI9dn+1RUyQsGo/QdWzj
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2002-11-27 at 00:25, thomas wrote:


> Where do the -15 and +15 come from and what do they actually map to?

They are windows priorities. They come from the win32 headers. We don't
map to *either* of them, because Cygwin is not suitable for running
programs at realtime priority and IIRC there was some iisue about
running at idle too.

> Also THREAD_PRIORITY_TIME_CRITICAL is not mapped in sched.cc to any UNIX
> priority so if an application calls

See above.

> SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS)
> SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL)
>=20
> what happens actually? As you already say in sched.cc: "We don't want
> process's going realtime" i guess it doesn't run at -20 but some other
> priority.

If you do that, expect to get a hung system real fast. Windows doesn't
avoid priority inversions, and the *only* programs that should run at
realtime priority are those designed for it. Cygwin is a general purpose
tool, and internally not quite up to running at realtime when I wrote
that mapping logic.

> >  those tests show nothing other than the time it takes to push the iso
> > through to a bitbucket. Unless there is serious other load on the CPU,
> > the time *should* be constant.
>=20
> I've run the test many times and they all give the same result,
> switching from nice -0 to nice --1 always gives a horrible delay, the
> cpu is not doing any other work at all during the test. But this seems
> to be an application specific problem and we're still investigating
> this.

What happens with nice -20 ?
=20
> While i was writing this i had the idea to do the same test with cat
> instead of mkisofs with a quite interesting result:
>=20
> $ time cat test.iso | nice -1 dd of=3D/dev/null
> real    0m7.171s
> user    0m2.466s
> sys     0m4.733s
>=20
> $ time cat test.iso | nice -0 dd of=3D/dev/null
> real    0m7.205s
> user    0m2.794s
> sys     0m4.467s
>=20
> $ time cat test.iso | nice --1 dd of=3D/dev/null
> real    1m51.428s
> user    0m0.107s
> sys     0m0.015s

Ah, I see it now, you expect a higher priority, and get less
performance.

What happens if you do this:
time nice --1 cat test.iso | nice --1 dd of=3D/dev/null ?

> I've briefly looked through the pre-1.3x sources and i can't find
> sched.cc there or sth. of the like, how was it handled back then?

sched.cc It was introduced around 1.1 IIRC. I may be remembering wrongly
:}. CVS is your friend.

Rob

--=20
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---

--=-VI9dn+1RUyQsGo/QdWzj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA949u6I5+kQ8LJcoIRApEsAJ0SbhT04Ir8aWAvImC1nImQMvA/jACeONC4
4xJBKNGfdByTpgjW6TJe/v8=
=Plk8
-----END PGP SIGNATURE-----

--=-VI9dn+1RUyQsGo/QdWzj--