All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	Ingo Molnar <mingo@elte.hu>,
	npiggin@suse.de, "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: Consolidated and improved smpnice patch
Date: Tue, 21 Feb 2006 17:21:47 +1100	[thread overview]
Message-ID: <43FAB17B.8020608@bigpond.net.au> (raw)
In-Reply-To: <200602210941.23352.kernel@kolivas.org>

[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]

Con Kolivas wrote:
> 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.

How does the attached patch grab you?  It's independent of HZ.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

[-- Attachment #2: smpnice-improve-weight-function --]
[-- Type: text/plain, Size: 1403 bytes --]

Index: MM-2.6.X/kernel/sched.c
===================================================================
--- MM-2.6.X.orig/kernel/sched.c	2006-02-21 16:27:32.000000000 +1100
+++ MM-2.6.X/kernel/sched.c	2006-02-21 17:01:12.000000000 +1100
@@ -169,13 +169,13 @@
 
 #define SCALE_PRIO(x, prio) \
 	max(x * (MAX_PRIO - prio) / (MAX_USER_PRIO/2), MIN_TIMESLICE)
+#define PRIO_TO_TS(sp) \
+	((sp) < NICE_TO_PRIO(0) ? SCALE_PRIO(DEF_TIMESLICE*4, (sp)) : \
+	 SCALE_PRIO(DEF_TIMESLICE, (sp)))
 
 static unsigned int task_timeslice(task_t *p)
 {
-	if (p->static_prio < NICE_TO_PRIO(0))
-		return SCALE_PRIO(DEF_TIMESLICE*4, p->static_prio);
-	else
-		return SCALE_PRIO(DEF_TIMESLICE, p->static_prio);
+	return PRIO_TO_TS(p->static_prio);
 }
 #define task_hot(p, now, sd) ((long long) ((now) - (p)->last_ran)	\
 				< (long long) (sd)->cache_hot_time)
@@ -680,11 +680,9 @@ static int effective_prio(task_t *p)
  */
 
 /*
- * Priority weight for load balancing ranges from 1/20 (nice==19) to 459/20 (RT
- * priority of 100).
+ * Priority weight for load balancing ranges (based on time slice allocations).
  */
-#define NICE_TO_LOAD_PRIO(nice) \
-	((nice >= 0) ? (20 - (nice)) : (20 + (nice) * (nice)))
+#define NICE_TO_LOAD_PRIO(nice) 	PRIO_TO_TS(NICE_TO_PRIO(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))

  reply	other threads:[~2006-02-21  6:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-20  5:02 [PATCH] sched: Consolidated and improved smpnice patch Peter Williams
2006-02-20 10:02 ` Con Kolivas
2006-02-20 22:35   ` Peter Williams
2006-02-20 22:41     ` Con Kolivas
2006-02-21  6:21       ` Peter Williams [this message]
2006-02-21  9:09         ` Con Kolivas
2006-02-22  0:30           ` Peter Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43FAB17B.8020608@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=suresh.b.siddha@intel.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.