re: elevator=as, or actually gpm doesn't get time from scheduler???

re: elevator=as, or actually gpm doesn't get time from scheduler???

[Antti Lankila]

In response to Nick Piggin's:

> The only other problems I can think of that you might be
> having are chipset problems, or CPU scheduler problems.
> Which reminds me, do you have your X server at nice 0?

X has been reniced to zero. But hey! I was doing "cat /dev/psaux" when mouse
stopped moving in X, and I _did_ see data coming from /dev/psaux! So this is
a major update to my understanding of the problem.

But make no mistake, I have been doing this cat /dev/psaux test earlier and
at that time I did _not_ see chars coming out of psaux when the mouse
stopped. That is why I thought I had established that the problem is in the
kernel. I must retest this on the other machines involved when I get to
their consoles next week. I can not explain why this time psaux appears to
work regardless of the userland mouse stall, so for now I must assume some
other factor confused the cat /dev/psaux test at that time.

My X reads gpmdata, so perhaps that's the problem? I now undercut gpm in
order to examine the situation, and my system behaves _perfectly_ as far as
I can see. The mouse issues are all gone. (gpm is still running in the
background, X just reads psaux directly. As I have understood, this is
possible in 2.6 while in 2.4 it caused a problem for multiple readers.)

I progress from now by removing gpm on all my systems.  There's still the
issue what gpm (or maybe kernel's scheduler) is doing wrong, I suppose.
Nevertheless, gpm is virtually useless for me and has so far caused far more
grief than its utility has ever been worth.

I'm sorry for having wasted your time with this.

Antti

Re: elevator=as, or actually gpm doesn't get time from scheduler???

[Helge Hafting]

Antti Lankila wrote:
> In response to Nick Piggin's:
> 
> 
>>The only other problems I can think of that you might be
>>having are chipset problems, or CPU scheduler problems.
>>Which reminds me, do you have your X server at nice 0?
> 
> 
> X has been reniced to zero. But hey! I was doing "cat /dev/psaux" when mouse
> stopped moving in X, and I _did_ see data coming from /dev/psaux! So this is
> a major update to my understanding of the problem.
> 
> But make no mistake, I have been doing this cat /dev/psaux test earlier and
> at that time I did _not_ see chars coming out of psaux when the mouse
> stopped. That is why I thought I had established that the problem is in the
> kernel. I must retest this on the other machines involved when I get to
> their consoles next week. I can not explain why this time psaux appears to
> work regardless of the userland mouse stall, so for now I must assume some
> other factor confused the cat /dev/psaux test at that time.
> 
> My X reads gpmdata, so perhaps that's the problem? I now undercut gpm in
> order to examine the situation, and my system behaves _perfectly_ as far as
> I can see. The mouse issues are all gone. (gpm is still running in the
> background, X just reads psaux directly. As I have understood, this is
> possible in 2.6 while in 2.4 it caused a problem for multiple readers.)
> 

Gpm might be a problem in high-load situations, for two reasons:

1. gpm is another process.  The mouse moves, it takes some time before gpm
   gets to read it because the cpu is busy.  Then it pass stuff onto the
   fifo that X reads from, but now X waits for a while because so much is going on.
2. You may play with the priority of x in order to get better response, but
   this does not affect the priority of gpm.

With X reading psaux directly, you avoid some waiting.  And X may get a priority
boost for waiting for the mouse to move. With gpm this bonus goes to gpm which
may have a lot less to do with it.

Helge Hafting

Re: elevator=as, or actually gpm doesn't get time from scheduler???

[Nick Piggin]

Antti Lankila wrote:

> My X reads gpmdata, so perhaps that's the problem? I now undercut gpm in
> order to examine the situation, and my system behaves _perfectly_ as far as
> I can see. The mouse issues are all gone. (gpm is still running in the
> background, X just reads psaux directly. As I have understood, this is
> possible in 2.6 while in 2.4 it caused a problem for multiple readers.)
> 
> I progress from now by removing gpm on all my systems.  There's still the
> issue what gpm (or maybe kernel's scheduler) is doing wrong, I suppose.
> Nevertheless, gpm is virtually useless for me and has so far caused far more
> grief than its utility has ever been worth.
> 
> I'm sorry for having wasted your time with this.
> 

Not at all, thank you for reporting the problem.

It seems the CPU scheduler is a bit fragile when there
are a number of interrelated processes. Note: I don't
know whether my scheduler fixes this case or not, it might
just be a difficult problem.