All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Pittman <daniel@rimspace.net>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Delaying writes to disk when there's no need
Date: Tue, 01 Apr 2003 10:43:22 +1000	[thread overview]
Message-ID: <87el4ngi8l.fsf@enki.rimspace.net> (raw)
In-Reply-To: <20030331144500.17bf3a2e.akpm@digeo.com> (Andrew Morton's message of "Mon, 31 Mar 2003 14:45:00 -0800")

On Mon, 31 Mar 2003, Andrew Morton wrote:
> Nick Piggin <piggin@cyberone.com.au> wrote:
>>
>> it seems to me that
>> doing writeout whenever the disk would otherwise be idle
>> (and we have dirty memory to write out) would be a good
>> solution.
> 
> This is what the recently-removed BDI_read_active flag in
> backing_dev_info was supposed to be for. I let it go because I don't
> think it's terribly important and it's time to stop fiddling with the
> vfs writeout code and it wasn't right anyway.
> 
> Note that 2.5 starts pdflush writeout at 10% of memory dirty. Or even
> lower if there is a lot of mapped memory around. Whereas 2.4 will
> start background writeout at 30% or 40% dirty. That's a fairly
> significant tuning change.

I don't figure it's a very important thing, but even this change doesn't
resolve one of the issues I have with the default writeout scheduler.

Capturing a real-time video stream from an IEEE1394 DV stream means
writing a stead 3.5MB per second for two on two and a half hours.

Linux isn't great at this, using the default writeout policy, even as
recent as 2.5.64. The writer goes OK for a while but, eventually, blocks
on writeout for long enough to drop a frame -- more than 8/25ths of a
second.


This can be resolved by tuning the default delay before write-out start
to 5 seconds, down from 30, or by running sync every second, or by doing
fsync tricks.


I think it's a good thing that you can delay writes for a long time, in
general, but there are cases where blocking *really* sucks and on a
system that does nothing else but produce 3.5MB per second of dirty
memory and write that to disk...

Well, something that allowed only that data stream to be preemptively
written out would be good without the need for the thread-and-fsync
trick.

        Daniel

-- 
Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps
learning stays young. The greatest thing in life is to keep your mind young.
        -- Henry Ford

  parent reply	other threads:[~2003-04-01  0:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-26 20:31 Delaying writes to disk when there's no need Erik Hensema
2003-03-27  9:06 ` Helge Hafting
2003-03-27 11:22   ` Erik Hensema
2003-03-28 23:12 ` Pavel Machek
2003-03-31 12:00   ` Erik Hensema
2003-03-31 13:42     ` Helge Hafting
2003-03-31 14:45       ` Oliver Neukum
2003-03-31 22:02       ` Nick Piggin
2003-03-31 22:22         ` Chris Friesen
2003-03-31 22:35           ` Nick Piggin
2003-03-31 22:51             ` John Bradford
2003-03-31 22:58               ` Nick Piggin
2003-03-31 22:45         ` Andrew Morton
2003-03-31 23:03           ` Nick Piggin
2003-03-31 23:32           ` Ingo Oeser
2003-04-01  0:02             ` Andrew Morton
2003-04-01  0:43           ` Daniel Pittman [this message]
2003-04-01  1:09             ` Andrew Morton
2003-04-01  1:34               ` Daniel Pittman
2003-04-01  1:45                 ` Andrew Morton
     [not found]               ` <3E88EB3D.6020409@cyberone.com.au>
2003-04-01  1:39                 ` Andrew Morton
     [not found] <20030326204012$188c@gated-at.bofh.it>
     [not found] ` <20030327091007$22a5@gated-at.bofh.it>
     [not found]   ` <20030327113014$37b4@gated-at.bofh.it>
2003-03-28 10:18     ` Tim Connors
2003-03-30 17:38       ` Helge Hafting

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=87el4ngi8l.fsf@enki.rimspace.net \
    --to=daniel@rimspace.net \
    --cc=akpm@digeo.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.