Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 07 Jul 2014 10:39:02 +0200
From:      Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
To:        John Baldwin <jhb@freebsd.org>
Cc:        J David <j.david.lists@gmail.com>, freebsd-stable@freebsd.org, Eric van Gyzen <eric@vangyzen.net>, avg@freebsd.org, dave@mischler.com
Subject:   Re: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1
Message-ID:  <53BA5CA6.1000100@omnilan.de>
In-Reply-To: <201309040958.48377.jhb@freebsd.org>
References:  <1375737316.96778.10.camel@firkin.mischler.com> <5203A90D.6020008@vangyzen.net> <5203AE08.30504@vangyzen.net> <201309040958.48377.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6778C81824F694A803DA13BC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bez=FCglich John Baldwin's Nachricht vom 04.09.2013 15:58 (localtime):
> On Thursday, August 08, 2013 10:41:12 am Eric van Gyzen wrote:
>> On 08/08/2013 09:19, Eric van Gyzen wrote:
>>> On 08/06/2013 14:23, J David wrote:
>>>> On Tue, Aug 6, 2013 at 1:59 PM, Eric van Gyzen <eric@vangyzen.net> w=
rote:
>>>>>> on an otherwise idle amd64 system with 4 CPUs.  The first command =
in=20
> the
>>>>>> build.log file:
>>>>>>
>>>>>>     rm -rf /usr/obj/home/freebsd/tmp
>>>>>>
>>>>>> took over three minutes.  It should have taken about three /second=
s/.
>>>>>>
>>>>>> "uptime" reported a load average of around 1.00.
>>>>>> "top" showed no threads (user or kernel) using CPU.
>>>>>> "iostat" showed an average of less than 20 tps on ada0.
>>>>>> "rm" was usually in the RUN state.
>>>> We are looking at something similar.  Would you be able to try to
>>>> reproduce it using a kernel with:
>>>>
>>>> nooptions	SCHED_ULE
>>>> options		SCHED_4BSD
>>>>
>>>> to see if it makes a difference?  It seems to, but the problem is
>>>> inconsistent enough that I can't be sure.
>>> The 4BSD scheduler does //not// exhibit this problem.  I tested with =
the
>>> latest releng/9.2 (r254054) and an otherwise GENERIC config.
>>
>> To be thorough, I built a GENERIC kernel at the same rev, and it still=

>> exhibits the problem.
>=20
> Please try this change:
>=20
> Index: sched_ule.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- sched_ule.c	(revision 255020)
> +++ sched_ule.c	(working copy)
> @@ -243,7 +243,7 @@ struct tdq {
>  	int		tdq_transferable;	/* Transferable thread count. */
>  	short		tdq_switchcnt;		/* Switches this tick. */
>  	short		tdq_oldswitchcnt;	/* Switches last tick. */
> -	u_char		tdq_lowpri;		/* Lowest priority thread. */
> +	u_short		tdq_lowpri;		/* Lowest priority thread. */
>  	u_char		tdq_ipipending;		/* IPI pending. */
>  	u_char		tdq_idx;		/* Current insert index. */
>  	u_char		tdq_ridx;		/* Current removal index. */
> @@ -2323,7 +2323,7 @@ sched_choose(void)
>  		tdq->tdq_lowpri =3D td->td_priority;
>  		return (td);
>  	}
> -	tdq->tdq_lowpri =3D PRI_MAX_IDLE;
> +	tdq->tdq_lowpri =3D PRI_MAX_IDLE + 1;
>  	return (PCPU_GET(idlethread));
>  }

Hello,

the fix above still applies cleanly to 9.3-RC3.
Was ist solved differently? Or just slipped through?

Thanks,

-Harry


--------------enig6778C81824F694A803DA13BC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAlO6XKsACgkQLDqVQ9VXb8ivlQCgzQ/Z/jlhW8w6rQJhAGteVP++
TNUAn0IYFuXcbAGxxk9j64usRBYfcFcb
=WUeF
-----END PGP SIGNATURE-----

--------------enig6778C81824F694A803DA13BC--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53BA5CA6.1000100>