Re: Data needed by userland scheduler [WAS: Re: Goals...]

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi !
:
:As I promised, a new and hopefully short thread.
:
:>>     You'd have to be a bit more specific.  Run and sleep times are 
:>> generally
:>>     accounted for.  The only scheduler-specific case I guess is how it 
:>> handles
:>>     wakeup after sleeping for a long period of time.
:Yes, but I'm not looking for accumulating timecounters. I know this gets
:done essentially in kern/kern_clock.c and marginally/purely adjusting in other places
:for the stats.
:
:What I want are informations like
:  * how long did the process contigueously run until it voluntarily slept ?
:    (minus the time it spent in interrupts during that period)
:    If it was stopped, the scheduler needs that information as well, but
:    will handle the process specially anyway...
:  * how long did the process sleep until it was woken up ?
:About these things I need some (constant) history of switches.
:(Like: "The last 5 run/sleep-switches for process p it ran 5 ms, then slept
:         for 25, then ran for 14, then...")
:
:For this to accomplish, I need two things:
:First, some struct fields to record this (easily done in struct sched e.g.)
:Second, some points to place hooks in. And this is my problem right now.
:For sleeping times, tsleep and endtsleep are presumably the best candidates.

    Yes, tsleep is the best candidate.  There is no need to mess around
    with endtsleep().  Just record 'ticks' before and after tsleep sleeps.
    Unlike FreeBSD, any user process sleeping in the kernel in DragonFly
    will have a kernel priority, so we don't need to mess with the priority
    prior to the wakeup, we can do it after the wakeup.

:But for running times ? As I already mentioned, I may be blind...
:I don't want to account the time it was on some lwkt-queue.
:Though this is somehow an abstraction of curproc, it might still be unfair.

    There is a per-cpu clock interrupt called statclock, see kern_clock.c,
    which statistically records run times in 'ticks', into the thread
    structure.

    All you need to do to get a contiguous run time is to add a field to
    the proc's scheduler helper structure (not the thread structure)
    to record td_uticks as of the last wakeup.  Then you can calculate the
    contiguous running time trivially.

:Also, I might add, that I don't want to make use of schedcpu, its estcpu cruft
:or any FOR_EACH_*. It should be made more event-driven. I think this would
:add to the goal "scalability".
:
:Cheers
:Peter
:
:-- 
:<peter.kadau@xxxxxxxxxxxxxxxx>

    Generally speaking in DragonFly all process timings are statistical
    in nature, because I refuse to make [get]microtime() calls in the
    critical path.  But this should be just fine for any scheduler's 
    operation.  If the delta ticks is 0 you can assume that it didn't
    sleep, even if it might have slept for up to a tick.  From a 
    statistical standpoint everything will come out properly after a
    few iterations.

    There is also a schedclock(), also in kern_clock.c, which runs at a
    10Hz rate (that the normal scheduler uses).  This is where you can 
    hook the course-grained scheduling check.  Actually, this code already
    calls another routine called schedulerclock(), which is in 
    kern_synch.c.  What I recommend is that you change schedclock() to
    be the following:

    /* schedulerclock(NULL) PREVIOUS CODE */
    if ((p = curproc) != NULL) {
	p->p_sched.schedulerclock(p);
	/* Update resource usage integrals and maximums. */
	.... (previous code) ....
    }

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>