lkml.org 
[lkml]   [2006]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] sched: Consolidated and improved smpnice patch
Date
On Tuesday 21 February 2006 09:35, Peter Williams wrote:
> Con Kolivas wrote:
> > On Monday 20 February 2006 16:02, Peter Williams wrote:
> > [snip description]
> >
> > Hi peter, I've had a good look and have just a couple of comments:
> >
> > ---
> > #endif
> > int prio, static_prio;
> > +#ifdef CONFIG_SMP
> > + int load_weight; /* for load balancing purposes */
> > +#endif
> > ---
> >
> > Can this be moved up to be part of the other ifdef CONFIG_SMP? Not highly
> > significant since it's in a .h file but looks a tiny bit nicer.
>
> I originally put it where it is to be near prio and static_prio which
> are referenced at the same time as it BUT that doesn't happen often
> enough to justify it anymore so I guess it can be moved.

Well it is just before prio instead of just after it now and I understand the
legacy of the position.

> > ---
> > +/*
> > + * Priority weight for load balancing ranges from 1/20 (nice==19) to
> > 459/20 (RT
> > + * priority of 100).
> > + */
> > +#define NICE_TO_LOAD_PRIO(nice) \
> > + ((nice >= 0) ? (20 - (nice)) : (20 + (nice) * (nice)))
> > +#define LOAD_WEIGHT(lp) \
> > + (((lp) * SCHED_LOAD_SCALE) / NICE_TO_LOAD_PRIO(0))
> > +#define NICE_TO_LOAD_WEIGHT(nice)
> > LOAD_WEIGHT(NICE_TO_LOAD_PRIO(nice)) +#define PRIO_TO_LOAD_WEIGHT(prio)
> > NICE_TO_LOAD_WEIGHT(PRIO_TO_NICE(prio))
> > +#define RTPRIO_TO_LOAD_WEIGHT(rp) \
> > + LOAD_WEIGHT(NICE_TO_LOAD_PRIO(-20) + (rp))
> > ---
> >
> > The weighting seems not related to anything in particular apart from
> > saying that -nice values are more heavily weighted.
>
> The idea (for the change from the earlier model) was to actually give
> equal weight to negative and positive nices. Under the old (purely
> linear) model a nice=19 task has 1/20th the weight of a nice==0 task but
> a nice==-20 task only has twice the weight of a nice==0 so that system
> is heavily weighted against negative nices. With this new mapping a
> nice=19 has 1/20th and a nice==-19 has 20 times the weight of a nice==0
> task and to me that is symmetric. Does that make sense to you?

Yes but what I meant is it's still an arbitrary algorithm which is why I
suggested proportional to tasks' timeslice because then it should scale with
the theoretically allocated cpu resource.

> Should I add a comment to explain the mapping?
>
> > Since you only do this when
> > setting the priority of tasks can you link it to the scale of
> > (SCHED_NORMAL) tasks' timeslice instead even though that will take a
> > fraction more calculation? RTPRIO_TO_LOAD_WEIGHT is fine since there
> > isn't any obvious cpu proportion relationship to rt_prio level.
>
> Interesting idea. I'll look at this more closely.

Would be just a matter of using task_timeslice(p) and making it proportional
to some baseline ensuring the baseline works at any HZ.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-20 23:44    [W:0.073 / U:3.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site