Re: [gentoo-user] Nice level for X11

[Daniel Iliev]

On Thu, 15 May 2008 19:45:17 +0100
Mick <michaelkintzios@×××××.com> wrote:

> On Thursday 15 May 2008, Alan McKinnon wrote:
> > On Thursday 15 May 2008, Abraham Gyorgy wrote:
> > > I know X runs always as root. But setting the X server process'
> > > priority to for example -10 makes graphical software response
> > > faster.
>
> Setting the X server to -10 may make the X more responsive to client
> requests - theoretically that is.  However, since this is a zero sum
> game, some other processes will be short changed.  So they may
> (theoretically again) run slower.  It could well be that your KDE
> session becomes slower as a result, ha!  Anyway, just looking at the
> info page I read: ===================================
> "  A niceness should not be confused with a scheduling priority, which
> lets applications determine the order in which threads are scheduled
> to run.  Unlike a priority, a niceness is merely advice to the
> scheduler, which the scheduler is free to ignore."
> ===================================
>
> Perhaps this is the reason why Linus has uttered his particular words
> of wisdom on this matter.
>
> > > It works for me!! (no matter the system hangs sometimes :).
> > > I think you have a fast machine, try it with a very slow computer
> > > (sempron processor and radeon xpress200m+fglrx).
>
> I have slow machine(s) and I tried your suggestion, but have not run
> any benchmarks.  I cannot sense a difference.
>
> > You'll probably get better results with X by selecting a suitable
> > process scheduler and configuring your HZ to 1000
>
> Now, this I have noticed making a difference.  Not all schedulers are
> born the same.  I have found that (the current version of) CFQ is
> better than others.
>

Please, correct me if I'm wrong.

I believe you're mixing the block device I/O SCHEDULERS (CFQ, deadline,
anticipatory) with the process scheduling PLOCIES (Real time, BATCH,
FIFO...). While the first are used to reorder the I/O requests to
optimise the head movements in HDDs, the latter define how the kernel
should divide the CPU time between processes and their threads.
Choosing one I/O scheduler over another may have some effect on the way
the X sessions behaves, but it would be indirect. Choosing one
scheduling policy over another for a given application has a direct
impact on its performance.


> As a matter of interest, I remember reading somewhere that squeezing
> 1000Hz out of an old machine may have the opposite effect to that
> intended.  Is this pub talk, or have you experienced something that
> confirms this?


There's a logic behind this claim. The timer frequency (as I understand
it) defines how many times per second a process can be interrupted
(making the CPU work on something else). The higher the frequency, the
smoother the experience, but at the cost of the time it takes a process
to finish.

Let's see what happens if for example you had a massive tar job (e.g.
archiving your $HOME) and wanted to use the system as usual at the same
time.

Case 1 - timer freq. = 1000Hz

Working with the system is (almost) as normal - fast responses, no delay
in switching windows and so on. Tar finishes its job for 30min.

Case 2 - timer freq. = 100Hz

The system is almost unusable. Switching windows takes several (tens
of) seconds, responses are extremely slow. The tar job is done after
10min.

So, too many interrupts in a saturated system (or slow CPU) would make
the CPU work a little on each job and start another w/o finishing
anything "in time".

(Again, please, correct me if I'm wrong)


-- 
Best regards,
Daniel
-- 
gentoo-user@l.g.o mailing list