Great. I'm running 4.02. How do I enable "silken mouse"?
Thanks,
-Michael
On 29 Apr 2001 14:44:11 -0700, Jim Gettys wrote:
> The biggest single issue in GUI responsiveness on Linux has been caused
> by XFree86's implementation of mouse tracking in user space.
>
> On typical UNIX systems, the m
The biggest single issue in GUI responsiveness on Linux has been caused
by XFree86's implementation of mouse tracking in user space.
On typical UNIX systems, the mouse was often controlled in the kernel
driver. Until recently (XFree86 4.0 days), the XFree86 server's reads
of mouse/keyboard event
Mike Galbraith wrote:
>
> On Fri, 27 Apr 2001, Nigel Gamble wrote:
>
> > On Fri, 27 Apr 2001, Mike Galbraith wrote:
> > > On Fri, 27 Apr 2001, Nigel Gamble wrote:
> > > > > What about SCHED_YIELD and allocating during vm stress times?
> > >
> > > snip
> > >
> > > > A well-written GUI should not
On Wed, Apr 25, 2001 at 10:02:26PM -0400, Dan Maas wrote:
> > Are there any negative effects of editing include/asm/param.h to change
> > HZ from 100 to 1024? Or any other number? This has been suggested as a
> > way to improve the responsiveness of the GUI on a Linux system.
[...]
> Of course, t
On Fri, 27 Apr 2001, Nigel Gamble wrote:
> On Fri, 27 Apr 2001, Mike Galbraith wrote:
> > On Fri, 27 Apr 2001, Nigel Gamble wrote:
> > > > What about SCHED_YIELD and allocating during vm stress times?
> >
> > snip
> >
> > > A well-written GUI should not be using SCHED_YIELD. If it is
> >
> > I w
On Fri, 27 Apr 2001, Mike Galbraith wrote:
> On Fri, 27 Apr 2001, Nigel Gamble wrote:
> > > What about SCHED_YIELD and allocating during vm stress times?
>
> snip
>
> > A well-written GUI should not be using SCHED_YIELD. If it is
>
> I was refering to the gui (or other tasks) allocating memory
On Fri, 27 Apr 2001, Nigel Gamble wrote:
> > What about SCHED_YIELD and allocating during vm stress times?
snip
> A well-written GUI should not be using SCHED_YIELD. If it is
I was refering to the gui (or other tasks) allocating memory during
vm stress periods, and running into the yield in _
On Fri, 27 Apr 2001, Mike Galbraith wrote:
> > Rubbish. Whenever a higher-priority thread than the current
> > thread becomes runnable the current thread will get preempted,
> > regardless of whether its timeslices is over or not.
>
> What about SCHED_YIELD and allocating during vm stress times?
;Mike Galbraith" <[EMAIL PROTECTED]>
To: "linux-kernel" <[EMAIL PROTECTED]>
Sent: Friday, April 27, 2001 6:04 AM
Subject: Re: #define HZ 1024 -- negative effects?
> > > I have not tried it, but I would think that setting HZ to 1024
> > &g
> > I have not tried it, but I would think that setting HZ to 1024
> > should make a big improvement in responsiveness.
> >
> > Currently, the time slice allocated to a standard Linux
> > process is 5*HZ, or 50ms when HZ is 100. That means that you
> > will notice keystrokes being echoed slowly i
t burn my house down :-)
Dan
- Original Message -
From: "Rik van Riel" <[EMAIL PROTECTED]>
To: "Adam J. Richter" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 2:31 PM
Subject: Re: #define HZ 1024 -- negative effects?
> On
On Thu, 26 Apr 2001, Adam J. Richter wrote:
> I have not tried it, but I would think that setting HZ to 1024
> should make a big improvement in responsiveness.
>
> Currently, the time slice allocated to a standard Linux
> process is 5*HZ, or 50ms when HZ is 100. That means that you
>
I have not tried it, but I would think that setting HZ to 1024
should make a big improvement in responsiveness.
Currently, the time slice allocated to a standard Linux process
is 5*HZ, or 50ms when HZ is 100. That means that you will notice
keystrokes being echoed slowly in X whe
On Wed, 25 Apr 2001, Dan Maas wrote:
> The only other possibility I can think of is a scheduler anomaly. A thread
> arose on this list recently about strange scheduling behavior of processes
> using local IPC - even though one process had readable data pending, the
> kernel would still go idle un
On Wed, 25 Apr 2001, Dan Maas wrote:
> > Are there any negative effects of editing include/asm/param.h to change
> > HZ from 100 to 1024? Or any other number? This has been suggested as a
> > way to improve the responsiveness of the GUI on a Linux system.
>
> I have also played around with HZ=102
> Are there any negative effects of editing include/asm/param.h to change
> HZ from 100 to 1024? Or any other number? This has been suggested as a
> way to improve the responsiveness of the GUI on a Linux system.
I have also played around with HZ=1024 and wondered how it affects
interactivity. I
Well, for kicks, I tried setting HZ to 1024 with 2.2.19. It seemed a
little more responsive, but that could be psychosomatic. :) I did notice
that I was unable to sync my palm pilot until I set it back to 100.
YMMV. The most useful "performace" tweak for a GUI that I've come across is:
#define
> > Are there any negative effects of editing include/asm/param.h to change
> > HZ from 100 to 1024? Or any other number? This has been suggested as a
> > way to improve the responsiveness of the GUI on a Linux system. Does it
...
> Why not just run the X server at a realtime priority? Then it
On Tue, 24 Apr 2001, Michael Rothwell wrote:
> Are there any negative effects of editing include/asm/param.h to change
> HZ from 100 to 1024? Or any other number? This has been suggested as a
> way to improve the responsiveness of the GUI on a Linux system. Does it
> throw off anything else, li
19 matches
Mail list logo
