| View previous topic :: View next topic |
| Author |
Message |
poke@ulyssis
n00b
Joined: 22 Feb 2003
Posts: 9
|
 Posted: Sun Mar 09, 2003 3:56 pm Post subject: nice -n and X |
 |
|
how and were can I set the nice priority for X ?
I taught that "nice -n 10" would be a good value? Or is this to high or low?
thx |
|
| Back to top |
|
 |
commanderfoxtrot
n00b
Joined: 07 Dec 2002
Posts: 40
Location: University of Durham, UK
|
| Posted: Sun Mar 09, 2003 7:09 pm Post subject: |
|
|
Find the PID of X by typing "ps ax|grep X"
and then renice it by:
renice -10 <PID>
e.g. is the PID of X is 1034
renice -10 1034
You will need to be root for this to work.
Renicing X to -10 is a common thing these days it would appear; but I've never seen the need for it personally. |
|
| Back to top |
|
|
mglauche
Retired Dev
Joined: 25 Apr 2002
Posts: 564
Location: Germany
|
| Posted: Sun Mar 09, 2003 7:58 pm Post subject: |
|
|
| there was an interesting bit about it these days on slashdot and kerneltrap.org ... basicly they are vastly improving the 2.5.6x scheduler for interactive programs... some interesting quotes are that linus thinks renicing X is a *very* bad idea ... |
|
| Back to top |
|
|
frenion
n00b
Joined: 25 Nov 2002
Posts: 26
|
| Posted: Sun Mar 09, 2003 8:32 pm Post subject: |
|
|
| Is it somehow possible to initiate this command each time the system is booted? |
|
| Back to top |
|
|
Evangelion
Veteran
Joined: 31 May 2002
Posts: 1087
Location: Helsinki, Finland
|
| Posted: Sun Mar 09, 2003 8:44 pm Post subject: |
|
|
| frenion wrote: | | Is it somehow possible to initiate this command each time the system is booted? |
You could write a script that is executed every time yuo run X. Someone posted a script like that in one thread, but I can't recall where. But I'm sure you can find it with bit of searching 
_________________
My tech-blog | My other blog |
|
| Back to top |
|
|
mglauche
Retired Dev
Joined: 25 Apr 2002
Posts: 564
Location: Germany
|
| Posted: Sun Mar 09, 2003 8:49 pm Post subject: |
|
|
here is the patch from linus and ingo against 2.5.64 that should impove X performance by a huge margin:
| Code: |
--- linux/include/linux/sched.h.orig
+++ linux/include/linux/sched.h
@@ -328,7 +328,7 @@ struct task_struct {
prio_array_t *array;
unsigned long sleep_avg;
- unsigned long sleep_timestamp;
+ unsigned long last_run;
unsigned long policy;
unsigned long cpus_allowed;
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -54,20 +54,19 @@
/*
* These are the 'tuning knobs' of the scheduler:
*
- * Minimum timeslice is 10 msecs, default timeslice is 150 msecs,
- * maximum timeslice is 300 msecs. Timeslices get refilled after
+ * Minimum timeslice is 10 msecs, default timeslice is 100 msecs,
+ * maximum timeslice is 200 msecs. Timeslices get refilled after
* they expire.
*/
#define MIN_TIMESLICE ( 10 * HZ / 1000)
-#define MAX_TIMESLICE (300 * HZ / 1000)
-#define CHILD_PENALTY 95
+#define MAX_TIMESLICE (200 * HZ / 1000)
+#define CHILD_PENALTY 50
#define PARENT_PENALTY 100
#define EXIT_WEIGHT 3
#define PRIO_BONUS_RATIO 25
#define INTERACTIVE_DELTA 2
-#define MAX_SLEEP_AVG (2*HZ)
-#define STARVATION_LIMIT (2*HZ)
-#define NODE_THRESHOLD 125
+#define MAX_SLEEP_AVG (10*HZ)
+#define STARVATION_LIMIT (10*HZ)
/*
* If a task is 'interactive' then we reinsert it in the active
@@ -323,26 +322,36 @@ static inline int effective_prio(task_t
* Also update all the scheduling statistics stuff. (sleep average
* calculation, priority modifiers, etc.)
*/
+static inline void __activate_task(task_t *p, runqueue_t *rq)
+{
+ enqueue_task(p, rq->active);
+ rq->nr_running++;
+}
+
static inline void activate_task(task_t *p, runqueue_t *rq)
{
- unsigned long sleep_time = jiffies - p->sleep_timestamp;
- prio_array_t *array = rq->active;
+ unsigned long sleep_time = jiffies - p->last_run;
if (!rt_task(p) && sleep_time) {
/*
* This code gives a bonus to interactive tasks. We update
* an 'average sleep time' value here, based on
- * sleep_timestamp. The more time a task spends sleeping,
+ * ->last_run. The more time a task spends sleeping,
* the higher the average gets - and the higher the priority
* boost gets as well.
*/
p->sleep_avg += sleep_time;
- if (p->sleep_avg > MAX_SLEEP_AVG)
+ if (p->sleep_avg > MAX_SLEEP_AVG) {
+ int ticks = p->sleep_avg - MAX_SLEEP_AVG + current->sleep_avg;
p->sleep_avg = MAX_SLEEP_AVG;
- p->prio = effective_prio(p);
+ if (ticks > MAX_SLEEP_AVG)
+ ticks = MAX_SLEEP_AVG;
+ if (!in_interrupt())
+ current->sleep_avg = ticks;
+ }
+ p->prio = effective_prio(p);
}
- enqueue_task(p, array);
- nr_running_inc(rq);
+ __activate_task(p, rq);
}
/*
@@ -479,10 +488,13 @@ repeat_lock_task:
}
if (old_state == TASK_UNINTERRUPTIBLE)
rq->nr_uninterruptible--;
- activate_task(p, rq);
-
- if (p->prio < rq->curr->prio)
- resched_task(rq->curr);
+ if (sync)
+ __activate_task(p, rq);
+ else {
+ activate_task(p, rq);
+ if (p->prio < rq->curr->prio)
+ resched_task(rq->curr);
+ }
success = 1;
}
p->state = TASK_RUNNING;
@@ -525,8 +537,16 @@ void wake_up_forked_process(task_t * p)
p->prio = effective_prio(p);
}
set_task_cpu(p, smp_processor_id());
- activate_task(p, rq);
+ if (unlikely(!current->array))
+ __activate_task(p, rq);
+ else {
+ p->prio = current->prio;
+ list_add_tail(&p->run_list, ¤t->run_list);
+ p->array = current->array;
+ p->array->nr_active++;
+ rq->nr_running++;
+ }
task_rq_unlock(rq, &flags);
}
@@ -953,6 +973,11 @@ static inline void pull_task(runqueue_t
*/
if (p->prio < this_rq->curr->prio)
set_need_resched();
+ else {
+ if (p->prio == this_rq->curr->prio &&
+ p->time_slice > this_rq->curr->time_slice)
+ set_need_resched();
+ }
}
/*
@@ -1016,7 +1041,7 @@ skip_queue:
*/
#define CAN_MIGRATE_TASK(p,rq,this_cpu) \
- ((jiffies - (p)->sleep_timestamp > cache_decay_ticks) && \
+ ((jiffies - (p)->last_run > cache_decay_ticks) && \
!task_running(rq, p) && \
((p)->cpus_allowed & (1UL << (this_cpu))))
@@ -1076,9 +1101,9 @@ DEFINE_PER_CPU(struct kernel_stat, kstat
* increasing number of running tasks:
*/
#define EXPIRED_STARVING(rq) \
- ((rq)->expired_timestamp && \
+ (STARVATION_LIMIT && ((rq)->expired_timestamp && \
(jiffies - (rq)->expired_timestamp >= \
- STARVATION_LIMIT * ((rq)->nr_running) + 1))
+ STARVATION_LIMIT * ((rq)->nr_running) + 1)))
/*
* This function gets called by the timer code, with HZ frequency.
@@ -1201,7 +1226,7 @@ need_resched:
rq = this_rq();
release_kernel_lock(prev);
- prev->sleep_timestamp = jiffies;
+ prev->last_run = jiffies;
spin_lock_irq(&rq->lock);
/*
@@ -1701,7 +1726,7 @@ static int setscheduler(pid_t pid, int p
else
p->prio = p->static_prio;
if (array)
- activate_task(p, task_rq(p));
+ __activate_task(p, task_rq(p));
out_unlock:
task_rq_unlock(rq, &flags);
--- linux/kernel/fork.c.orig
+++ linux/kernel/fork.c
@@ -916,7 +917,7 @@ static struct task_struct *copy_process(
*/
p->first_time_slice = 1;
current->time_slice >>= 1;
- p->sleep_timestamp = jiffies;
+ p->last_run = jiffies;
if (!current->time_slice) {
/*
* This case is rare, it happens when the parent has only
|
|
|
| Back to top |
|
|
bsolar
Bodhisattva
Joined: 12 Jan 2003
Posts: 2764
|
| Posted: Sun Mar 09, 2003 9:32 pm Post subject: |
|
|
| mglauche wrote: | | there was an interesting bit about it these days on slashdot and kerneltrap.org ... basicly they are vastly improving the 2.5.6x scheduler for interactive programs... some interesting quotes are that linus thinks renicing X is a *very* bad idea ... |
I think Torvalds was against that (the other good points he mentioned apart) because it was a way to "avoid" a problem instead of finding a solution for it.
_________________
I may not agree with what you say, but I'll defend to the death your right to say it. |
|
| Back to top |
|
|
mglauche
Retired Dev
Joined: 25 Apr 2002
Posts: 564
Location: Germany
|
| Posted: Mon Mar 10, 2003 9:51 am Post subject: |
|
|
| yes, thats correct ... btw .. I did try 2.5.64 plus that patch above, and its a *huge* improvement to 2.4.20-gentoo-r1 ! window dragging is really smooth and everything seems a lot more responsitive ... plus 2.5.64 supports v4l2 with saa7134 out of the box, so the choice is easy |
|
| Back to top |
|
|
narensankar
Tux's lil' helper
Joined: 04 Nov 2002
Posts: 109
|
| Posted: Mon Mar 10, 2003 4:45 pm Post subject: |
|
|
| There is a potential problem with X at nice -10. Apps that require close to real time performance - xmms, mplayer etc. have problems with performance. My personal experience on a dual proc 1.7 Ghz Xeon desktop is that with X at -10, mplayer has problems with video and starts to skip frames. I have mozilla running as well and this creates problems for mplayer. Removing the nice on X fixed the problem. This was one of Linus's comments as well. Latency dependant applications will suffer in performance with X at -10. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
