public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Andrew Morton <akpm@digeo.com>
Cc: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: iosched: impact of streaming read on read-many-files
Date: Tue, 25 Feb 2003 13:02:47 +0100	[thread overview]
Message-ID: <20030225120247.GA663@zaurus.ucw.cz> (raw)
In-Reply-To: <20030221131158.180125d7.akpm@digeo.com>

Hi!

> > mplayer or xmms will never skip frames, not for parallel cp reading
> > floods of data at max speed like a database with zillon of threads. For
> > multimedia not to skip frames 1M/sec is  more than enough bandwidth,
> > doesn't matter if the huge database in background runs much slower as
> > far as you never skip a frame.
> 
> These applications are broken.  The kernel shouldn't be bending over
> backwards trying to fix them up.  Because this will never ever work as well
> as fixing the applications.
> 
> The correct way to design such an application is to use an RT thread to
> perform the display/audio device I/O and a non-RT thread to perform the disk

I do not think this can be done easily.
For mplayer case you'd need to mlock
X server...

And emacs/vi/all interactive tasks
 are in similar situation (latency matters),
are you going to make them all realtime?

-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...


  parent reply	other threads:[~2003-02-24 20:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-21  5:23 IO scheduler benchmarking Andrew Morton
2003-02-21  5:23 ` iosched: parallel streaming reads Andrew Morton
2003-02-21  5:24 ` iosched: effect of streaming write on interactivity Andrew Morton
2003-02-21  5:25 ` iosched: effect of streaming read " Andrew Morton
2003-02-21  5:25 ` iosched: time to copy many small files Andrew Morton
2003-02-21  5:26 ` iosched: concurrent reads of " Andrew Morton
2003-02-21  5:27 ` iosched: impact of streaming write on streaming read Andrew Morton
2003-02-21  5:27 ` iosched: impact of streaming write on read-many-files Andrew Morton
2003-02-21  5:27 ` iosched: impact of streaming read " Andrew Morton
2003-02-21 10:40   ` Andrea Arcangeli
2003-02-21 10:55     ` Nick Piggin
2003-02-21 11:23       ` Andrea Arcangeli
2003-02-21 21:11     ` Andrew Morton
2003-02-23 15:16       ` Andrea Arcangeli
2003-02-25 12:02       ` Pavel Machek [this message]
2003-02-21  5:28 ` iosched: effect of streaming read on streaming write Andrew Morton
2003-02-21  6:51 ` IO scheduler benchmarking David Lang
2003-02-21  8:16   ` Andrew Morton
2003-02-21 10:31     ` Andrea Arcangeli
2003-02-21 10:51       ` William Lee Irwin III
2003-02-21 11:08         ` Andrea Arcangeli
2003-02-21 11:17           ` Nick Piggin
2003-02-21 11:41             ` Andrea Arcangeli
2003-02-21 21:25               ` Andrew Morton
2003-02-23 15:09                 ` Andrea Arcangeli
2003-02-21 11:34           ` William Lee Irwin III
2003-02-21 12:38             ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030225120247.GA663@zaurus.ucw.cz \
    --to=pavel@suse.cz \
    --cc=akpm@digeo.com \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox