I am having a problem with the RT preempt kernels where xscreensaver
will cause the X server to consume excessive CPU, starving other
processes. This should not happen as xscreensaver runs at the highest
nice value. It seems that there's some kind of priority inversion
happening between the high prio X server and low prio xscreensaver.
This seems like an X problem to me, but could the kernel be involved?
Lee
does this still occur with the latest tree? (.47-05 or later)
Ingo
* Lee Revell <[email protected]> wrote:
> I am having a problem with the RT preempt kernels where xscreensaver
> will cause the X server to consume excessive CPU, starving other
> processes. This should not happen as xscreensaver runs at the highest
> nice value. It seems that there's some kind of priority inversion
> happening between the high prio X server and low prio xscreensaver.
>
> This seems like an X problem to me, but could the kernel be involved?
>
> Lee
remember that the low pri screensaver is just generating the image to be
displayed, it's the high pri X server that's actually doing the work to
display it.
David Lang
On Mon, 23 May 2005, Ingo Molnar wrote:
> does this still occur with the latest tree? (.47-05 or later)
>
> Ingo
>
> * Lee Revell <[email protected]> wrote:
>
>> I am having a problem with the RT preempt kernels where xscreensaver
>> will cause the X server to consume excessive CPU, starving other
>> processes. This should not happen as xscreensaver runs at the highest
>> nice value. It seems that there's some kind of priority inversion
>> happening between the high prio X server and low prio xscreensaver.
>>
>> This seems like an X problem to me, but could the kernel be involved?
>>
>> Lee
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
Le lun 23/05/2005 ? 09:55, Ingo Molnar a ?crit :
> does this still occur with the latest tree? (.47-05 or later)
>
> Ingo
>
> * Lee Revell <[email protected]> wrote:
>
> > I am having a problem with the RT preempt kernels where xscreensaver
> > will cause the X server to consume excessive CPU, starving other
> > processes. This should not happen as xscreensaver runs at the highest
> > nice value. It seems that there's some kind of priority inversion
> > happening between the high prio X server and low prio xscreensaver.
> >
> > This seems like an X problem to me, but could the kernel be involved?
I have a problem with X too. It could be the same.
I have a test program which made a loop in RT to mesure the system perturbation.
It works finely in a tty environment.
When I run it in an X environment ( xterm ), I get something like if I click the Enter key.
If I open a new xterm, this is the active window which receive these events.
These events stop when the program stop.
On Mon, 2005-05-23 at 01:11 -0700, David Lang wrote:
> remember that the low pri screensaver is just generating the image to be
> displayed, it's the high pri X server that's actually doing the work to
> display it.
>
Understood. It still seems like a bug that a lowly screensaver can
wedge the X server to the point that it consumes all available CPU.
This is a DoS - you can barely ssh in.
Lee
On Mon, 2005-05-23 at 01:11 -0700, David Lang wrote:
> remember that the low pri screensaver is just generating the image to be
> displayed, it's the high pri X server that's actually doing the work to
> display it.
Then there needs to be some mechanism to handle it, either in X or the
kernel. Other OSes do not require you to turn off the screensaver to
avoid a DoS - they do the obvious thing and run the screensaver at the
lowest priority.
The problem may be software 3D rendering (I did not have the VIA driver
enabled as I did not realize it was in the kernel yet). Maybe the X
server should do the work in a low priority thread. But it sure
shouldn't DoS the system. Other OSes do not have this problem.
Lee
On Mon, 2005-05-23 at 09:55 +0200, Ingo Molnar wrote:
> does this still occur with the latest tree? (.47-05 or later)
I'll retest with the latest version. It's still present in
2.6.12-rc4-RT-V0.7.47-01.
Do you think the kernel could be involved? It's looking more like an X
problem to me.
Lee
On Fri, 27 May 2005, Lee Revell wrote:
> On Mon, 2005-05-23 at 01:11 -0700, David Lang wrote:
>> remember that the low pri screensaver is just generating the image to be
>> displayed, it's the high pri X server that's actually doing the work to
>> display it.
>
> Then there needs to be some mechanism to handle it, either in X or the
> kernel. Other OSes do not require you to turn off the screensaver to
> avoid a DoS - they do the obvious thing and run the screensaver at the
> lowest priority.
>
> The problem may be software 3D rendering (I did not have the VIA driver
> enabled as I did not realize it was in the kernel yet). Maybe the X
> server should do the work in a low priority thread. But it sure
> shouldn't DoS the system. Other OSes do not have this problem.
Actually they don't (or at least didn't the last time I took windows
training), if you have a CPU intensive screen saver on a windows server it
will seriously load down the box when it kicks in.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On Fri, 2005-05-27 at 10:34 -0700, David Lang wrote:
> On Fri, 27 May 2005, Lee Revell wrote:
>
> > On Mon, 2005-05-23 at 01:11 -0700, David Lang wrote:
> >> remember that the low pri screensaver is just generating the image to be
> >> displayed, it's the high pri X server that's actually doing the work to
> >> display it.
> >
> > Then there needs to be some mechanism to handle it, either in X or the
> > kernel. Other OSes do not require you to turn off the screensaver to
> > avoid a DoS - they do the obvious thing and run the screensaver at the
> > lowest priority.
> >
> > The problem may be software 3D rendering (I did not have the VIA driver
> > enabled as I did not realize it was in the kernel yet). Maybe the X
> > server should do the work in a low priority thread. But it sure
> > shouldn't DoS the system. Other OSes do not have this problem.
>
> Actually they don't (or at least didn't the last time I took windows
> training), if you have a CPU intensive screen saver on a windows server it
> will seriously load down the box when it kicks in.
That was a problem in the NT 4.0 days, but not lately.
Lee
On Fri, 27 May 2005, Lee Revell wrote:
> On Fri, 2005-05-27 at 10:34 -0700, David Lang wrote:
>> On Fri, 27 May 2005, Lee Revell wrote:
>>
>>> On Mon, 2005-05-23 at 01:11 -0700, David Lang wrote:
>>>> remember that the low pri screensaver is just generating the image to be
>>>> displayed, it's the high pri X server that's actually doing the work to
>>>> display it.
>>>
>>> Then there needs to be some mechanism to handle it, either in X or the
>>> kernel. Other OSes do not require you to turn off the screensaver to
>>> avoid a DoS - they do the obvious thing and run the screensaver at the
>>> lowest priority.
>>>
>>> The problem may be software 3D rendering (I did not have the VIA driver
>>> enabled as I did not realize it was in the kernel yet). Maybe the X
>>> server should do the work in a low priority thread. But it sure
>>> shouldn't DoS the system. Other OSes do not have this problem.
>>
>> Actually they don't (or at least didn't the last time I took windows
>> training), if you have a CPU intensive screen saver on a windows server it
>> will seriously load down the box when it kicks in.
>
> That was a problem in the NT 4.0 days, but not lately.
Ok, it has been a while since I had windows training (and I DON'T miss it ;-)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare