Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Oct 2007 03:16:49 +0200 (CEST)
From:      "P.U.Kruppa" <ulrich@pukruppa.net>
To:        Kris Kennaway <kris@freebsd.org>
Cc:        "\[LoN\]Kamikaze" <LoN_Kamikaze@gmx.de>, freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: SCHED_4BSD in RELENG_7 disturbs workflow
Message-ID:  <20071017030940.R1559@small>
In-Reply-To: <47150F82.9060805@FreeBSD.org>
References:  <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--207141057-945791779-1192583809=:1559
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 16 Oct 2007, Kris Kennaway wrote:

> [LoN]Kamikaze wrote:
>> I know that RELENG_7 is not considered very near-release, but I thought =
I'd
>> give my 2=A2 in the hope that I might have a little influence on the=20
>> scheduler
>> development to my benefit.
>>=20
>> The switch from RELENG_6 to RELENG_7 went relatively smooth and apart fr=
om=20
>> ipw
>> causing panics. However there is one thing that's disturbing and this is=
=20
>> the
>> scheduler. I only have single core machines, so whatever I say only appl=
ies=20
>> to
>> those. If you think single-core machines are no longer important, feel f=
ree=20
>> to
>> ignore this. In deed, just ignore me however much you like.
>>=20
>>> From my perspective scheduling on RELENG_6 was way better. Even on a fu=
ll
>> workload like a portupgrade the focused application (both in X and on th=
e
>> console) always received enough cycles to run smoothly and applications=
=20
>> that
>> ran in background like audio players also kept on running fine.
>>=20
>> Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgd=
b=20
>> -L'
>> (recovering lost dependencies) audio players (both graphical and mplayer=
)
>> scatter, either because they don't get the hard-disk or CPU-cycles (whic=
h=20
>> one,
>> I don't know) and the focused application also often hangs. It just look=
s=20
>> like
>> occasionally (under load) everything freezes for a second and then goes =
on
>> relatively normal.
>>=20
>> I've got the impression that things compile a little faster (that might =
be=20
>> my
>> imagination, though), but I'd rather have a smooth working experience.
>>=20
>> This is just my view of the situation and I suppose it is only one of ma=
ny.=20
>> I
>> bid you be merciful with us single-core people, who cannot afford a slic=
k
>> multi-core machine, because we worry how to pay for our food at the end =
of=20
>> the
>> month.
>
> Not to say that any problems that might have developed with SCHED_4BSD sh=
ould=20
> not be fixed, but you should give SCHED_ULE a try since it brings benefit=
s=20
> even for single CPU systems (e.g. better interactive response).
I would like to second that. I have seen the same problems on my=20
single processor system and using SCHED_ULE instead of SCHED_4BSD=20
seems to improve the situation a lot.

Uli.
>
> Kris
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org=
"
>



Peter Ulrich Kruppa
Wuppertal
Germany

--207141057-945791779-1192583809=:1559--



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