[Clfs-support] Process scheduling and chrt

Ken Moffat zarniwhoop at ntlworld.com
Tue Apr 15 15:06:21 PDT 2008


On Tue, Apr 15, 2008 at 07:42:00PM +0530, jignesh gangani wrote:
> Thanks ken.
> 
> I started to notice things when I was copying large files to and fro
> (but not frequently),
> writing CDs etc (when I note load average is around 2-3 and no
> dominant process exist), I see my box becomes sluggish. On the
> contrary, I have seen Linux distribution performing better (than mine)
> in such situation(s). It May be because I am running Beryl or few
> services extra (ntp, clamd and likes) but I think my processor (AMD64)
> and my graphics card (NVIDIA 6600GT to handle Beryl) are fast enough
> to cope up with these situations. Otherwise I am happy with my Linux
> box. My concern was is it because I am not running some critical
> services (kswapd, migration(?), and disk driver) with real time
> priority, the PC is becoming sluggish? I will try util-linux-ng. Are
> there any performance enhancement pointers that my fellow (C/B)LFS
> users have noted? I am unable to find any in LFS archives.
> 
> 
 My server (x86_64-64) used to be sluggish when I was comparing two
large files on the same partition (that is, when running cmp against
a tarball, and the backup copy of it which I'd read from tape, and
sluggish as in "skips when typing in vim, or delays when advancing
through mail in mutt).  In that case, I was on the cfq scheduler -
changing it to deadline (/sys/block/sdX/queue/scheduler) helped,
changing it to noop helped some more.  Possibly, a different
scheduler might help in other cases, or not - for my desktops I'm
happy with cfq.

 If clamd is as resource hungry as windows virus scanners (I've no
idea if it is or isn't), that would explain a lot.

 I don't know about 'migration', whatever that is, but kswapd and
the disk driver are part of the kernel.  That real-time priority
indication in 'top' might just be a patch to alter _how_ top
displays things.  Or, perhaps the distros you looked at have the
"real-time" patches in their kernels (but, I would have thought that
unlikely for RHEL).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the Clfs-support mailing list