Message-ID: <4AB72FDC.5090403@datenparkplatz.de>
Date: Mon, 21 Sep 2009 09:48:44 +0200
From: Ulrich Lukas <stellplatz-nr.13a@datenparkplatz.de>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
CC: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Poor desktop responsiveness with background I/O-operations
References: <4AB59CBB.8090907@datenparkplatz.de>	 <20090920080728.73bfe2a1@infradead.org>	 <4AB5ECD0.7010903@datenparkplatz.de>	 <1253475521.9224.43.camel@marge.simson.net>  <4AB6C73C.1030004@gmail.com> <1253507034.23414.90.camel@marge.simson.net>
In-Reply-To: <1253507034.23414.90.camel@marge.simson.net>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
To: unlisted-recipients:; (no To-header on input)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 870
Lines: 24

Hi and thanks for your reply!


Mike Galbraith wrote:
> nicing a shell or the dd should (and does) help a LOT.

If this is the only way to influence this, maybe the default settings
for the niceness of interactive and non-interactive tasks are not the
best choice. (Maybe a distribution problem in this case)


> reads are sync, more heavily affected by seek latency than writes.

But how does this explain the seconds-long delays?

If an interactive process causes a lot of seeks because of reads/writes
which "are sync", I see how this can greatly slow down otherwise
pipelined write operations, but the other way around?
--
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/