Mike Galbraith <[email protected]> wrote:
>
> On Fri, 2006-03-17 at 22:22 -0800, Andrew Morton wrote:
> > Mike Galbraith <[email protected]> wrote:
> > >
> > > > Does this have to be a macro?
> > > >
> > >
> > > I suppose not, now inlined.
> > >
> >
> > It would be nice to uninline the function and then to modify it in a
> > followup patch. That way, we get to see what changed, which is one of the
> > reasons to not use megamacros (sorry).
>
> Ok, take 3 below, with updated main comment as well.
>
Thanks for doing that. Not really your job, but someone has to do these
things ;)
>
> Signed-off-by: Mike Galbraith <[email protected]>
You can't trick me that easily - I kept a copy of your changlog!
> /*
> + * We place interactive tasks back into the active array, if possible.
> + *
> + * To guarantee that this does not starve expired tasks we ignore the
> + * interactivity of a task if the first expired task had to wait more
> + * than a 'reasonable' amount of time. This deadline timeout is
> + * load-dependent, as the frequency of array switched decreases with
> + * increasing number of running tasks. We also ignore the interactivity
> + * if a better static_prio task has expired, and switch periodically
> + * regardless, to ensure that highly interactive tasks do not starve
> + * the less fortunate for unreasonably long periods.
> + */
> +static int expired_starving(runqueue_t *rq)
I'll make that inline..
> +{
> + int limit;
> +
> + /*
> + * Arrays were recently switched, all is well.
> + */
> + if (!rq->expired_timestamp)
> + return 0;
> +
> + limit = STARVATION_LIMIT * rq->nr_running;
In the previous iteration you had, effectively,
if (!limit)
return 0;
in here. But it's now gone. Deliberate?
> + /*
> + * It's time to switch arrays.
> + */
> + if (jiffies - rq->expired_timestamp >= limit)
> + return 1;
> +
> + /*
> + * There's a better selection in the expired array.
> + */
> + if (rq->curr->static_prio > rq->best_expired_prio)
> + return 1;
> +
> + /*
> + * All is well.
> + */
> + return 0;
> +}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
