mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andrew Morton <akpm@digeo.com>, Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [ak@suse.de: Re: iosched: impact of streaming read on read-many-files]
Date: Sun, 23 Feb 2003 20:05:08 +0100	[thread overview]
Message-ID: <20030223200508.N21727@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <20030223154002.GG29467@dualathlon.random>; from andrea@suse.de on Sun, Feb 23, 2003 at 04:40:02PM +0100

On Sun, Feb 23, 2003 at 04:40:02PM +0100, Andrea Arcangeli wrote:
> On Sat, Feb 22, 2003 at 02:57:28PM +0100, Ingo Oeser wrote:
> > What about implementing io-requests, which can time out? So if it will
> > not be serviced in time or we know, that it will not be serviced
> > in time, we can skip that.
> 
> that works only if the congestion cames from multimedia apps that are
> willing to cancel the timed out (now worthless) I/O, that is never the
> case normally due the low I/O load they generate (usually it's apps not
> going to cancel the I/O that congest the blkdev layer).
 
I would put it to loads, where it doesn't matter that all streams
will be serviced all the time and where it does matter more, that
we stay responsive and show the latest frames available.

> still, it's a good idea, you're basically asking to implement the cancel
> aio api and I doubt anybody could disagree with that ;).

I'm aware of these, but if we are so heavily busy, that the
applications looses IO frames already, then calling into an
application (which might be swapped out) to traverse its
AIO overhead the cancel makes no sense any more.

I want a deadline attached to them and have them automatically
cancelled after this deadline. (that's why I quoted the relevant
part of my e-mail again).

I can see many uses besides multi media applications. Also http
or ftp server could do this, if they are busier as expected or if
a connection dropped.

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

  reply	other threads:[~2003-02-23 19:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-22  5:43 Andi Kleen
2003-02-22  7:07 ` Andrew Morton
2003-02-22 13:57   ` Ingo Oeser
2003-02-23 15:40     ` Andrea Arcangeli
2003-02-23 19:05       ` Ingo Oeser [this message]
2003-02-23 23:32         ` Andrea Arcangeli
2003-02-22 18:11   ` Alan Cox
2003-02-23 15:34   ` 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=20030223200508.N21727@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=ak@suse.de \
    --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

all inboxes | Powered by JetHome®