From: Dave Chinner <david@fromorbit.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: Dirty deleted files cause pointless I/O storms (unless truncated first)
Date: Tue, 21 Jan 2014 15:46:32 +1100 [thread overview]
Message-ID: <20140121044632.GA25923@dastard> (raw)
In-Reply-To: <CALCETrVT29DULWg16_oKpGgSSBwZh-yWtygV1oYjH5iQH5jGyg@mail.gmail.com>
On Mon, Jan 20, 2014 at 04:59:23PM -0800, Andy Lutomirski wrote:
> The code below runs quickly for a few iterations, and then it slows
> down and the whole system becomes laggy for far too long.
>
> Removing the sync_file_range call results in no I/O being performed at
> all (which means that the kernel isn't totally screwing this up), and
> changing "4096" to SIZE causes lots of I/O but without
> the going-out-to-lunch bit (unsurprisingly).
More details please. hardware, storage, kernel version, etc.
I can't reproduce any slowdown with the code as posted on a VM
running 3.31-rc5 with 16GB RAM and an SSD w/ ext4 or XFS. The
workload is only generating about 80 IOPS on ext4 so even a slow
spindle should be able handle this without problems...
> Surprisingly, uncommenting the ftruncate call seems to fix the
> problem. This suggests that all the necessary infrastructure to avoid
> wasting time writing to deleted files is there but that it's not
> getting used.
Not surprising at all - if it's stuck in a writeback loop somewhere,
truncating the file will terminate writeback because it end up being
past EOF and so stops immediately...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: Dirty deleted files cause pointless I/O storms (unless truncated first)
Date: Tue, 21 Jan 2014 15:46:32 +1100 [thread overview]
Message-ID: <20140121044632.GA25923@dastard> (raw)
In-Reply-To: <CALCETrVT29DULWg16_oKpGgSSBwZh-yWtygV1oYjH5iQH5jGyg@mail.gmail.com>
On Mon, Jan 20, 2014 at 04:59:23PM -0800, Andy Lutomirski wrote:
> The code below runs quickly for a few iterations, and then it slows
> down and the whole system becomes laggy for far too long.
>
> Removing the sync_file_range call results in no I/O being performed at
> all (which means that the kernel isn't totally screwing this up), and
> changing "4096" to SIZE causes lots of I/O but without
> the going-out-to-lunch bit (unsurprisingly).
More details please. hardware, storage, kernel version, etc.
I can't reproduce any slowdown with the code as posted on a VM
running 3.31-rc5 with 16GB RAM and an SSD w/ ext4 or XFS. The
workload is only generating about 80 IOPS on ext4 so even a slow
spindle should be able handle this without problems...
> Surprisingly, uncommenting the ftruncate call seems to fix the
> problem. This suggests that all the necessary infrastructure to avoid
> wasting time writing to deleted files is there but that it's not
> getting used.
Not surprising at all - if it's stuck in a writeback loop somewhere,
truncating the file will terminate writeback because it end up being
past EOF and so stops immediately...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2014-01-21 4:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 0:59 Dirty deleted files cause pointless I/O storms (unless truncated first) Andy Lutomirski
2014-01-21 0:59 ` Andy Lutomirski
2014-01-21 4:46 ` Dave Chinner [this message]
2014-01-21 4:46 ` Dave Chinner
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=20140121044632.GA25923@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
/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.