On Thu, 18 Nov 2010 21:30:16 +0100
"O. Hartmann" <ohart...@mail.zedat.fu-berlin.de> wrote:
> On 11/18/10 19:55, Lucius Windschuh wrote:
> > 2010/11/18 Andriy Gapon<a...@freebsd.org>:
> >> [Grouping of processes into TTY groups]
> >>
> >> Well, I think that those improvements apply only to a very specific usage
> >> pattern
> >> and are greatly over-hyped.
> >
> > But there are serious issue if you use FreeBSD as a desktop OS with
> > SMP and SCHED_ULE, or?
> > Because currently, my machine is barely usable if a compile job with
> > parallelism is running. Movies stutter, Firefox hangs. And even nice
> > -n 20 doesn't do the job in every case, as +20 seems not to be the
> > idle priority anymore?!?
> > And using "idprio 1 $cmd" as a workaround is, well, a kludge.
> > I am not sure if TTY grouping is the right solution, if you look at
> > potentially CPU-intensive GUI applications that all run on the same
> > TTY (or no TTY at all? Same problem).
> > Maybe, we could simply enhance the algorithm that decides if a task is
> > interactive? That would also improve the described situation.
> >
> > Regards,
> >
> > Lucius
>
> Stuttering Response, being stuck for over 20 seconds also happens when I
> start updating the OS' sources via svn. This happens on all boxes, some
> of them do have 8 cores (ob two CPUs) and plenty of RAM. Heavy disk I/O,
> doesn't matter on UFS2 or ZFS, also brings boxes to stutter, those
> phenomena are most seen when you interact with the machine via X11
> clients. I think it's hard to realize if a server only does console I/O,
> but console also seems to be stuck sometimes. It would be worth checking
> this with some 'benchmark'. X11 in its kind of oldish incarnation on
> FreeBSD seems to contribute most to those slowdowns, what so ever.
I guess schedulers can hardly distinguish heavy disk I/Os from nanosleep()s
and user-interactions; schedulers think both as voluntary sleep.
To make the matters worse, the current implementation of SCHED_ULE reassigns
ts_slice on sched_wakeup() no matter how short the sleep was.
I have a dumb local hack to grant ts_slice proportional to the duration
the waking thread slept rather than unconditionally reset to sched_slice.
--- sys/kern/sched_ule.c.orig
+++ sys/kern/sched_ule.c
@@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td)
u_int hzticks;
hzticks = (ticks - slptick) << SCHED_TICK_SHIFT;
+ if (hzticks > SCHED_SLP_RUN_MAX)
+ hzticks = SCHED_SLP_RUN_MAX;
ts->ts_slptime += hzticks;
+ /* Grant additional slices after we sleep. */
+ ts->ts_slice += hzticks / tickincr;
+ if (ts->ts_slice > sched_slice)
+ ts->ts_slice = sched_slice;
sched_interact_update(td);
sched_pctcpu_update(ts);
}
- /* Reset the slice value after we sleep. */
- ts->ts_slice = sched_slice;
sched_add(td, SRQ_BORING);
}
--
-|-__ YAMAMOTO, Taku
| __ < <t...@tackymt.homeip.net>
- A chicken is an egg's way of producing more eggs. -
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
