Re: [PATCH] [request for inclusion] Realtime LSM

[Chris Wright]

* Jack O'Quin (joq@xxxxxx) wrote:
> Ingo Molnar <mingo@xxxxxxx> writes:
> > you are right, i forgot about kernel threads. If they are nice -10 on
> > Jack's system too then they are within striking range indeed, especially
> > since they are typically idle and if then they are active for short
> > bursts of time and get the maximum boost. Jack, could you renice these
> > to -5, to make sure they dont interfere?
> 
> Sure.  My system does have some of these running at nice -10.  Where
> (how) do I change them?

For a one off test you can brute force it with the plain old renice(8).
Or (depending on which kernel you're using -- Con changed this post
2.6.10) you can apply a patch like:

diff -Nru a/kernel/workqueue.c b/kernel/workqueue.c
--- a/kernel/workqueue.c	2005-01-11 20:26:26 -08:00
+++ b/kernel/workqueue.c	2005-01-11 20:26:26 -08:00
@@ -188,7 +188,7 @@
 
 	current->flags |= PF_NOFREEZE;
 
-	set_user_nice(current, -10);
+	set_user_nice(current, -5);
 
 	/* Block and flush all signals */
 	sigfillset(&blocked);

> BTW, let's not lose sight of the fact that `nice --20 foo' requires
> CAP_SYS_NICE just like SCHED_FIFO does.  From a privilege perspective,
> this recurses to the same (still unsolved) problem.  

Yup, not forgotten ;-)

> Chris's rlimits proposal was the only workable suggestion I've seen
> for that.  Is there any hope of doing something like that in the 2.6.x
> timeframe?  

Yes there is.  We've made other rlimits changes in 2.6, and this one isn't
that invasive.  The main issues are:  getting semantics right, making sure
it actually solves the problem, making sure it keeps sane defaults (not
creating some new ugly hole), and making sure it's in step with the Grand
Plan (TM).  None of these issues are showstoppers, all quite workable.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/