public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Matt Mackall <mpm@selenic.com>
Cc: David Chinner <dgc@sgi.com>, Andi Kleen <andi@firstfloor.org>,
	xfs-oss <xfs@oss.sgi.com>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/9]: Reduce Log I/O latency
Date: Thu, 22 Nov 2007 14:41:06 +1100	[thread overview]
Message-ID: <20071122034106.GV114266761@sgi.com> (raw)
In-Reply-To: <20071122025726.GG17536@waste.org>

On Wed, Nov 21, 2007 at 08:57:27PM -0600, Matt Mackall wrote:
> On Thu, Nov 22, 2007 at 12:12:14PM +1100, David Chinner wrote:
> > In all the cases that I know of where ppl are using what could
> > be considered real-time I/O (e.g. media environments where they
> > do real-time ingest and playout from the same filesystem) the
> > real-time ingest processes create the files and do pre-allocation
> > before doing their I/O. This I/O can get held up behind another
> > process that is not real time that has issued log I/O. 
> > 
> > Given there is no I/O priority inheritence and having log I/O stall
> > will stall the entire filesystem, we cannot allow log I/O to
> > stall in real-time environments. Hence it must have the highest
> > possible priority to prevent this.
> 
> I've seen PVRs that would be upset by this. They put media on one
> filesystem and database/apps/swap/etc. on another, but have everything
> on a single spindle. Stalling a media filesystem read for a write
> anywhere else = fail.

Sounds like the PVR is badly designed to me. If a write can cause a
read to miss a playback deadline, then you haven't built enough
buffering into your playback application.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  reply	other threads:[~2007-11-22  3:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20071122003339.GH114266761__34694.2978365861$1195691722$gmane$org@sgi.com>
2007-11-22  0:49 ` [PATCH 2/9]: Reduce Log I/O latency Andi Kleen
2007-11-22  1:12   ` David Chinner
2007-11-22  2:57     ` Matt Mackall
2007-11-22  3:41       ` David Chinner [this message]
2007-11-22  7:25         ` Matt Mackall
2007-11-22 10:31           ` David Chinner
2007-11-22 18:10             ` Matt Mackall
2007-11-22 22:29               ` David Chinner
2007-11-22 23:09                 ` David Chinner
2007-11-23  0:21                   ` Matt Mackall
2007-11-23  0:20                 ` Matt Mackall
2007-11-22  3:28     ` Stewart Smith
2007-11-22 12:06       ` Andi Kleen
2007-11-22 13:15         ` David Chinner
2007-11-23  2:53           ` Andi Kleen
2007-11-23  4:03             ` David Chinner
2007-11-23 12:01               ` Andi Kleen
2007-11-24 18:43                 ` Matt Mackall
2007-11-22  0:33 David Chinner
2007-11-26  2:11 ` Lachlan McIlroy

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=20071122034106.GV114266761@sgi.com \
    --to=dgc@sgi.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=xfs@oss.sgi.com \
    /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