lkml.org 
[lkml]   [2006]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Sluggish system responsiveness on I/O
Date
Am Samstag, 18. November 2006 14:25 schrieb Prakash Punnoor:
> Am Samstag 18 November 2006 14:12 schrieb Christian:
> > So I tried to nice the make and see what happens:
> >
> > nice 5 make -j4: Seems to make no difference. Heavy stuttering in
> > glxgears and et
> > nice 10 make -j4: Somewhat better but still unusable with et
> >
> > everything above nice 15 is usable. nice 19 has full interactivity, that
> > means you can't make out a difference between no load and kernel compile
> > while playing enemy-territory.
> >
> > I suspect that it has something to do with the priority boost for I/O
> > hogs. But if this is a "general" scheduler problem, then why aren't more
> > people complaining about this?
>
> I complained about this a year ago, but not much has changed. :-( It gets
> esp bad if you copy GB size files (the writes are the problemmakers, less
> the reads) - no matter which io scheduler I use, though using deadline
> seems to lessen the impact a little bit. And I don't find it acceptable to
> have to play around with nice to get a responsible desktop, esp when one is
> using a GUI.
>
> Cheers,

Ah yes, you put me on the right track! So we can say that we are actually
talking about two different classes of problems here.

The first class is process scheduler related. An I/O intensive process which
is CPU intensive at the same time gets such a high priority boost, that it
harms multimedia interactivity. This leads to short interruptions
("stuttering") in multimedia apps eg. glxgears.

The second problem is (CFQ) I/O scheduler related. Multiple readers get a
fairly nice sharing of I/O bandwidth but as soon as you introduce a single
writer, this writer harms the readers very much.

The first problem can be mitigated by using nice. Since that is why we have
nice at all. You can also use another scheduling class like SCHED_BATCH.

The second problem is much more pressuring for the average desktop user.
While multiple readers are running, you click on the kmenu and it loads slower
than normal. This is what you expect from sharing bandwidth with same I/O
nice level processes. The I/O bandwidth is shared equally. If you want a fast
desktop renice the streaming readers with ionice. Distros could also ionice
the desktop processes like kicker with a low nice level. The real problem for
desktop "interactivity" is when you are running streaming writers and then
trigger short reads eg. with the kmenu. It happens that the read request gets
starved for about a minute(!!) or even more.

Some use-cases:
glxgears with heavy read I/O: no problems
glxgears with heavy write I/O: no problems

glxgears with a "read,compute" load: stuttering due to priority boost

kmenu with several readers: slightly slower, equally shared bandwith. Ability
to use ionice
kmenu with several writers: unusable

So I think the major problem here is the starvation of short reads while
running multiple streaming writers. That deffinitely needs to be adressed.
This would be the last real problem that I see with a fully maxed out Linux
machine. Linux now has one of the best process and I/O schedulers I have ever
seen. Thanks to the great work of Jens Axboe and all the other nice people.
If this last wart would be attacked than I would consider Linux for total
World domination ;-)

-Christian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-11-18 15:43    [W:0.055 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site