* Michal Schmidt <[EMAIL PROTECTED]> wrote:
> Allow the administrator to change kthreadd's priority and affinity.
> Ensure that the kernel threads are created with the usual nice level
> and affinity even if kthreadd's properties were changed from the
> default.
>
> Signed-off-by: Michal
On Mon, 7 Jan 2008 09:29:56 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > > > This causes a practical problem. When a runaway real-time task
> > > > is eating 100% CPU and we attempt to put the CPU offline,
>
On Mon, 7 Jan 2008 09:29:56 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
This causes a practical problem. When a runaway real-time task
is eating 100% CPU and we attempt to put the CPU offline,
sometimes we
* Michal Schmidt [EMAIL PROTECTED] wrote:
Allow the administrator to change kthreadd's priority and affinity.
Ensure that the kernel threads are created with the usual nice level
and affinity even if kthreadd's properties were changed from the
default.
Signed-off-by: Michal Schmidt
On Mon, 2008-01-07 at 09:29 -0800, Andrew Morton wrote:
> On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > > > This causes a practical problem. When a runaway real-time task is
> > > > eating 100% CPU and we attempt to put the CPU offline, sometimes we
> > >
On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > This causes a practical problem. When a runaway real-time task is
> > > eating 100% CPU and we attempt to put the CPU offline, sometimes we
> > > block while waiting for the creation of the highest-priority
> > >
Hello Michal,
> > Maybe we can find a way to use a similar mechanism as I used in my
> > patchset for the priorities of the remaining kthreads.
> > I do not like the way of forcing userland to change the priorities,
> > because that would require a userland with the chrt tool installed,
> > and
On Mon, 7 Jan 2008 02:25:13 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2008 11:06:03 +0100 Michal Schmidt
> <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 22 Dec 2007 01:30:21 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 17 Dec 2007 23:43:14 +0100 Michal
On Mon, 7 Jan 2008 12:22:51 +0100
"Remy Bohmer" <[EMAIL PROTECTED]> wrote:
> Hello Michal and Andrew,
>
> > Let's not make the decision for the user. Just allow the
> > administrator to change kthreadd's priority safely if he chooses to
> > do it. Ensure that the kernel threads are created with
Hello Michal and Andrew,
> Let's not make the decision for the user. Just allow the administrator to
> change kthreadd's priority safely if he chooses to do it. Ensure that the
> kernel threads are created with the usual nice level even if kthreadd's
> priority is changed from the default.
Last
> > This causes a practical problem. When a runaway real-time task is
> > eating 100% CPU and we attempt to put the CPU offline, sometimes we
> > block while waiting for the creation of the highest-priority
> > "kstopmachine" thread.
sched-devel.git has new mechanisms against runaway RT
On Mon, 7 Jan 2008 11:06:03 +0100 Michal Schmidt <[EMAIL PROTECTED]> wrote:
> On Sat, 22 Dec 2007 01:30:21 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 17 Dec 2007 23:43:14 +0100 Michal Schmidt
> > <[EMAIL PROTECTED]> wrote:
> >
> > > kthreadd, the creator of other kernel
On Sat, 22 Dec 2007 01:30:21 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Dec 2007 23:43:14 +0100 Michal Schmidt
> <[EMAIL PROTECTED]> wrote:
>
> > kthreadd, the creator of other kernel threads, runs as a normal
> > priority task. This is a potential for priority inversion when a
This causes a practical problem. When a runaway real-time task is
eating 100% CPU and we attempt to put the CPU offline, sometimes we
block while waiting for the creation of the highest-priority
kstopmachine thread.
sched-devel.git has new mechanisms against runaway RT tasks. There's
Hello Michal and Andrew,
Let's not make the decision for the user. Just allow the administrator to
change kthreadd's priority safely if he chooses to do it. Ensure that the
kernel threads are created with the usual nice level even if kthreadd's
priority is changed from the default.
Last
On Mon, 7 Jan 2008 12:22:51 +0100
Remy Bohmer [EMAIL PROTECTED] wrote:
Hello Michal and Andrew,
Let's not make the decision for the user. Just allow the
administrator to change kthreadd's priority safely if he chooses to
do it. Ensure that the kernel threads are created with the usual
On Mon, 7 Jan 2008 02:25:13 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 7 Jan 2008 11:06:03 +0100 Michal Schmidt
[EMAIL PROTECTED] wrote:
On Sat, 22 Dec 2007 01:30:21 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 23:43:14 +0100 Michal Schmidt
[EMAIL
Hello Michal,
Maybe we can find a way to use a similar mechanism as I used in my
patchset for the priorities of the remaining kthreads.
I do not like the way of forcing userland to change the priorities,
because that would require a userland with the chrt tool installed,
and that is not
On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
This causes a practical problem. When a runaway real-time task is
eating 100% CPU and we attempt to put the CPU offline, sometimes we
block while waiting for the creation of the highest-priority
kstopmachine
On Mon, 2008-01-07 at 09:29 -0800, Andrew Morton wrote:
On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
This causes a practical problem. When a runaway real-time task is
eating 100% CPU and we attempt to put the CPU offline, sometimes we
block while
20 matches
Mail list logo
