On Thu, 15 May 2008 19:45:17 +0100 Mick <[EMAIL PROTECTED]> 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@lists.gentoo.org mailing list
