Date: Tue, 9 Mar 2004 12:01:23 -0800 From: Wes Peters <wes@softweyr.com> To: Robert Watson <rwatson@freebsd.org>, Bin Ren <br260@cam.ac.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: a serious error in sched_ule.c? Message-ID: <200403091201.23665.wes@softweyr.com> In-Reply-To: <Pine.NEB.3.96L.1040309113959.26895J-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040309113959.26895J-100000@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
On Tuesday 09 March 2004 08:41 am, Robert Watson wrote:
> On 9 Mar 2004, Bin Ren wrote:
> >
> > I've been reading sched_ule.c and seem to find a serious error:
> >
> > in 'sched_slice()':
> >
> > * Rationale:
> > * KSEs in interactive ksegs get the minimum slice so that we
> > * quickly notice if it abuses its advantage.
> > .....
> > #define SCHED_SLICE_INTERACTIVE (slice_max)
> >
> > (slice_max) for interactive KSEs???? Either this is a serious mistake
> > or I'm seriously missing sth here.
>
> I believe this is a synchronization error in the comment and the code.
> The code was changed to provide a maximum slice to interactive
> applications because non-CPU intensive X11 applications will be marked as
> interactive, but redraws get interrupted in a short slice. When the
> change went in to increase the time slice I saw an observable improvement
> in the redraws of X11 apps under load.
One of the classic trade-offs in making a 'server' vs. 'workstation'
operating system. Workstations require a strong preference for interactive
over background tasks so the interactive tasks will remain responsive,
especially in terms of heavily event-driven tasks like graphical UIs. For
a true server, where interactive tasks are not the norm, this preference
may be counter-productive.
Is there some way (boot hint?) we could change SCHED_SLICE_INTERACTIVE
between slice_max and something approaching slice_min?
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters wes@softweyr.com
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403091201.23665.wes>