On Mon 07-03-05 23:30:57, Jack O'Quin wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > Matt Mackall <[EMAIL PROTECTED]> wrote:
> >>
> >> I think Chris Wright's last rlimit patch is more sensible and ready to
> >> go.
> >
> > I must say that I like rlimits - very straightforward, although
Matt Mackall <[EMAIL PROTECTED]> writes:
> On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote:
>> >> 4. is undocumented and has never been tested in any real music studios
>> >
>> > Well you'll have a bit to test it before it goes to Linus.
>>
>> Only toy tests will be possible without t
On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote:
> >> 4. is undocumented and has never been tested in any real music studios
> >
> > Well you'll have a bit to test it before it goes to Linus.
>
> Only toy tests will be possible without the required userspace tools.
Chris posted the re
>> Andrew Morton <[EMAIL PROTECTED]> writes:
>> > Does anyone have serious objections to this approach?
> On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote:
>> 1. is likely to introduce multiuser system security holes like the one
>> created recently when the mlock() rlimits bug was fix
On Tue, 8 Mar 2005, Lee Revell wrote:
> I am still confused about why the LSM framework was merged in the first
> place.
The purpose of LSM is to allow different security models to be
implemented. IMHO, a security model here meaning a complete or otherwise
significantly enhancing system-wide fra
On Tue, 2005-03-08 at 21:20 +, Christoph Hellwig wrote:
> On Tue, Mar 08, 2005 at 01:55:55PM -0500, Lee Revell wrote:
> > And as I mentioned a few times, the authors have neither the inclination
> > nor the ability to do that, because they are not kernel hackers. The
> > realtime LSM was writt
On Tue, Mar 08, 2005 at 01:55:55PM -0500, Lee Revell wrote:
> And as I mentioned a few times, the authors have neither the inclination
> nor the ability to do that, because they are not kernel hackers. The
> realtime LSM was written by users (not developers) of the kernel, to
> solve a specific re
Paul Davis <[EMAIL PROTECTED]> wrote:
>
> >And as I mentioned a few times, the authors have neither the inclination
> >nor the ability to do that, because they are not kernel hackers. The
> >realtime LSM was written by users (not developers) of the kernel, to
> >solve a specific real world problem
On Mon, 2005-03-07 at 20:33 -0800, Matt Mackall wrote:
> On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> >
> > So I still have the rt-lsm patch floating about, saying "merge me, merge
> > me!". I'm not sure that the world would end were I to do so.
> >
> > Consider this a prod i
>And as I mentioned a few times, the authors have neither the inclination
>nor the ability to do that, because they are not kernel hackers. The
>realtime LSM was written by users (not developers) of the kernel, to
>solve a specific real world problem. No one ever claimed it was the
>correct solut
On Tue, 2005-03-08 at 04:32 +, Christoph Hellwig wrote:
> and as I mentioned a few times if we really want to go for a magic
> uid/gid-based approach we should at least have one that's useable for
> all capabilities so it can replace the oracle hack aswell. But the
> proponents of the patch we
On Mon, Mar 07, 2005 at 10:55:35PM -0800, Andrew Morton wrote:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
> >
> > Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> > priorities. Defaults to traditional behavior. Originally written by
> > Chris Wright.
>
> It needs some din
Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
It needs some dinking with because Ingo has been playing games in my
resource.h. Here's the e
On Mon, Mar 07, 2005 at 10:45:05PM -0800, Chris Wright wrote:
> * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> > > Consider this a prod in the direction of those who were pushing
> > > alternatives ;)
> >
> > I think Chris Wright's la
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> > Consider this a prod in the direction of those who were pushing
> > alternatives ;)
>
> I think Chris Wright's last rlimit patch is more sensible and ready to
> go. And I think I may have
* Chris Wright <[EMAIL PROTECTED]> wrote:
> > Yes. In kernel "damage control" is an optional extra not a necessity
> > with this solution. Not so sure about with the RT LSB solution though.
>
> This has one advantage over RT LSM in that area, which is it places an
> upper bound on the priorit
* Peter Williams ([EMAIL PROTECTED]) wrote:
> But the patch you describe still seems a little loose to me in that it
> doesn't control both which users AND which programs they can run.
> Although I suppose that can be managed by suitable setting of file
> permissions?
rlimits are typically hand
On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > Matt Mackall <[EMAIL PROTECTED]> wrote:
> >>
> >> I think Chris Wright's last rlimit patch is more sensible and ready to
> >> go.
> >
> > I must say that I like rlimits - very straightfo
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I don't object to rlimits per se and I think that they are useful but
not as a sole solution to this problem. Being able to give a task
preferential treatment is a permissions issue and should be solved as
one.
Having RT cpu usage lim
On Tue, Mar 08, 2005 at 04:40:02PM +1100, Peter Williams wrote:
> The granting of the ability to switch to and from RT mode should require
> a means to specify which users it applies to and also which programs it
> applies to. The RT rlimits mechanism doesn't meet these criteria.
a) rlimits are
* Peter Williams ([EMAIL PROTECTED]) wrote:
> Andrew Morton wrote:
> >Matt Mackall <[EMAIL PROTECTED]> wrote:
> >
> >>I think Chris Wright's last rlimit patch is more sensible and ready to
> >>go.
> >
> >
> >I must say that I like rlimits - very straightforward, although somewhat
> >awkward to use
* Peter Williams <[EMAIL PROTECTED]> wrote:
> I don't object to rlimits per se and I think that they are useful but
> not as a sole solution to this problem. Being able to give a task
> preferential treatment is a permissions issue and should be solved as
> one.
>
> Having RT cpu usage limits o
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> Add a pair of rlimits for allowing non-root tasks to raise nice and rt
> priorities. Defaults to traditional behavior. Originally written by
> Chris Wright.
>
> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
this too looks good to me.
Acked-by: In
Andrew Morton wrote:
Matt Mackall <[EMAIL PROTECTED]> wrote:
I think Chris Wright's last rlimit patch is more sensible and ready to
go.
I must say that I like rlimits - very straightforward, although somewhat
awkward to use from userspace due to shortsighted shell design.
Does anyone have serious
Andrew Morton <[EMAIL PROTECTED]> writes:
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>>
>> I think Chris Wright's last rlimit patch is more sensible and ready to
>> go.
>
> I must say that I like rlimits - very straightforward, although somewhat
> awkward to use from userspace due to shortsighted
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> Still. It seems to be what we deserve if all that fancy stuff we have
>> cannot address this very simple and very real-world problem.
Ingo Molnar <[EMAIL PROTECTED]> writes:
> please describe this "very simple and very real-world problem" in simp
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> On Tue, Mar 08, 2005 at 04:32:50AM +, Christoph Hellwig wrote:
> > On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote:
> > > > please describe this "very simple and very real-world problem" in simple
> > > > terms. Lets make sure "problem"
On Tue, Mar 08, 2005 at 04:32:50AM +, Christoph Hellwig wrote:
> On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote:
> > > please describe this "very simple and very real-world problem" in simple
> > > terms. Lets make sure "problem" and "solution" didnt become detached.
> > >
> >
Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> I think Chris Wright's last rlimit patch is more sensible and ready to
> go.
I must say that I like rlimits - very straightforward, although somewhat
awkward to use from userspace due to shortsighted shell design.
Does anyone have serious objections to
On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
>
> So I still have the rt-lsm patch floating about, saying "merge me, merge
> me!". I'm not sure that the world would end were I to do so.
>
> Consider this a prod in the direction of those who were pushing
> alternatives ;)
I thin
On Mon, Mar 07, 2005 at 08:28:21PM -0800, Andrew Morton wrote:
> > please describe this "very simple and very real-world problem" in simple
> > terms. Lets make sure "problem" and "solution" didnt become detached.
> >
>
> Well others can do that better than I but I'd describe it as
>
> - Audio a
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > next we
> > > $CAPABILITY for $FOO and we're headed straight to interface-hell.
> >
> > "interface hell"? Wow.
> >
> > Still. It seems to be what we deserve if all that fancy stuff we have
> > cann
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > next we
> > $CAPABILITY for $FOO and we're headed straight to interface-hell.
>
> "interface hell"? Wow.
>
> Still. It seems to be what we deserve if all that fancy stuff we have
> cannot address this very simple and very real-world problem.
ple
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
> >
> > So I still have the rt-lsm patch floating about, saying "merge me, merge
> > me!". I'm not sure that the world would end were I to do so.
> >
> > Consider this a prod in the di
On Mon, Mar 07, 2005 at 07:50:20PM -0800, Andrew Morton wrote:
>
> So I still have the rt-lsm patch floating about, saying "merge me, merge
> me!". I'm not sure that the world would end were I to do so.
>
> Consider this a prod in the direction of those who were pushing
> alternatives ;)
It's s
So I still have the rt-lsm patch floating about, saying "merge me, merge
me!". I'm not sure that the world would end were I to do so.
Consider this a prod in the direction of those who were pushing
alternatives ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > Or, should that be?
> >
> > if (prio > 0 && prio <= 20 && policy != SCHED_NORMAL) {
>
> Or you can just drop the 'prio == 1 &&' part for this test. Ingo was
> trying to be clever to allow some RT bits, but that's not really
> necessary.
actuall
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> JACK actually uses three different priorities, the defaults are 9, 10
> and 20. How about if I change this test?
>
> if (prio <= 20 && policy != SCHED_NORMAL) {
yeah, this is OK. 20 is used for the watchdog thread, right? (so it has
minimal late
> > @@ -3211,6 +3211,12 @@ static inline task_t *find_process_by_pi
> > static void __setscheduler(struct task_struct *p, int policy, int prio)
> > {
> > BUG_ON(p->array);
> > + if (prio == 1 && policy != SCHED_NORMAL) {
> > + p->policy = SCHED_NORMAL;
> > + p->static_pr
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> i'm not suggesting that this is the way to go, it's just to test how
>> nice--20 tasks would perform (on the hacked kernel). We still dont
>> have this data, because in the other tests you tried, some
>> non-hi
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i'm not suggesting that this is the way to go, it's just to test how
> nice--20 tasks would perform (on the hacked kernel). We still dont
> have this data, because in the other tests you tried, some
> non-highprio threads got nice--20 priority as well, w
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> Adding a tid field is relatively easy. Fixing the race condition
> between setting it in the new thread and using it in the creating
> thread is harder, but not impossible. But, even setting it in the new
> thread would create an incompatible interface
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> In the absence of any documentation, I'm guessing about storing the
>> nice value in the priority field of the sched_param struct. But, I
>> have not been able to figure out how to make that work.
>
> the call
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> In the absence of any documentation, I'm guessing about storing the
> nice value in the priority field of the sched_param struct. But, I
> have not been able to figure out how to make that work.
the call you need is:
setpriority(PRIO_PROCESS, t
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> Is it possible to call sched_setscheduler() with a thread ID instead
>> of a pid? That's what I really need. JACK sets and resets the thread
>> priorities from a different thread.
>
> yes. The PID arguments i
* Sytse Wielinga <[EMAIL PROTECTED]> wrote:
> We are talking about two different things here. POSIX is just about
> API and has, correct me if I'm wrong, nothing to do with system calls
> whatsoever. The manpage nice(2) is about the libc library call nice(),
> which is per-process, which it shoul
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> Is it possible to call sched_setscheduler() with a thread ID instead
> of a pid? That's what I really need. JACK sets and resets the thread
> priorities from a different thread.
yes. The PID arguments in these APIs are all treated as 'TIDs'. One day
t
On Sun, Jan 16, 2005 at 05:57:23PM -0600, Jack O'Quin wrote:
> > * Jack O'Quin <[EMAIL PROTECTED]> wrote:
> >> According to the manpage, nice(2) is per-process not per-thread. That
> >> does not give the granularity we need.
>
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> > the manpage is incorrec
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>> According to the manpage, nice(2) is per-process not per-thread. That
>> does not give the granularity we need.
Ingo Molnar <[EMAIL PROTECTED]> writes:
> the manpage is incorrect - sys_nice() is per-thread. (Btw., you could
> use setpriority() too.)
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> Studying the test script, I discovered that it starts a separate
> program running in the background. So, I hacked the script to run it
> with nice -15 in order not to interfere with the realtime threads. The
> XRUNS didn't get much better, but the maxi
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> According to the manpage, nice(2) is per-process not per-thread. That
> does not give the granularity we need.
the manpage is incorrect - sys_nice() is per-thread. (Btw., you could
use setpriority() too.)
Ingo
-
To unsubscribe from this list:
Jack O'Quin <[EMAIL PROTECTED]> writes:
> *** Terminated Sat Jan 15 18:15:13 CST 2005 ***
> * SUMMARY RESULT
> Total seconds ran . . . . . . : 300
> Number of clients . . . . . . :20
> Ports per client . . . . . . : 4
> Frames per buffer . . . . . . :64
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>> could you try the patch below? The above patch wasnt enough. With the
>> patch below we turn off the starvation limits for nice --20 tasks only.
>> This is still a hack only. If we cannot make nice --20 perform like
>> RT-prio-1 then there's some probl
Mike Galbraith <[EMAIL PROTECTED]> writes:
> At 07:14 PM 1/14/2005 -0600, Jack O'Quin wrote:
>>Mike Galbraith <[EMAIL PROTECTED]> writes:
>>
>> > At 05:31 PM 1/13/2005 -0600, Jack O'Quin wrote:
>> >>Yes. However, my tests have so far shown a need for "actual FIFO as
>> >>long as the task behaves
>> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>>> One major problem: this `nice --20' hack affects every thread, not
>>> just the critical realtime ones. That's not what we want. Audio
>>> applications make very conscious choices which threads run with high
>>> priority and which do not.
> Ingo
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> --- kernel/sched.c~ Fri Dec 24 15:35:24 2004
>> +++ kernel/sched.c Wed Jan 12 23:48:49 2005
>> @@ -95,7 +95,7 @@
>> #define MAX_BONUS (MAX_USER_PRIO * PRIO_BONUS_RATIO / 100)
>> #define INTERACTIVE_DELTA 2
>> #define MAX_SLEEP_AVG
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> OK, I reran with just 5 processes reniced from -10 to -5. On my
>> system they were: events, khelper, kblockd, aio and reiserfs. In
>> addition, I reniced loop0 from -20 to -5.
>
>> One major problem: this `n
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> --- kernel/sched.c~ Fri Dec 24 15:35:24 2004
> +++ kernel/sched.cWed Jan 12 23:48:49 2005
> @@ -95,7 +95,7 @@
> #define MAX_BONUS(MAX_USER_PRIO * PRIO_BONUS_RATIO / 100)
> #define INTERACTIVE_DELTA 2
> #define MAX_SLEEP_AVG
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> OK, I reran with just 5 processes reniced from -10 to -5. On my
> system they were: events, khelper, kblockd, aio and reiserfs. In
> addition, I reniced loop0 from -20 to -5.
> One major problem: this `nice --20' hack affects every thread, not
> just
At 07:14 PM 1/14/2005 -0600, Jack O'Quin wrote:
Mike Galbraith <[EMAIL PROTECTED]> writes:
> At 05:31 PM 1/13/2005 -0600, Jack O'Quin wrote:
>>Yes. However, my tests have so far shown a need for "actual FIFO as
>>long as the task behaves itself."
>
> I for one wonder why that appears to be so. Wh
60 matches
Mail list logo
