From: Jan Kara <jack@suse.cz>
To: Chris Friesen <chris.friesen@genband.com>
Cc: Jan Kara <jack@suse.cz>, Alex Bligh <alex@alex.org.uk>,
Michal Hocko <mhocko@suse.cz>,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: Local DoS through write heavy I/O on CFQ & Deadline
Date: Fri, 19 Oct 2012 00:24:49 +0200 [thread overview]
Message-ID: <20121018222449.GA19204@quack.suse.cz> (raw)
In-Reply-To: <50807F26.5070106@genband.com>
On Thu 18-10-12 16:13:58, Chris Friesen wrote:
> On 10/18/2012 03:28 PM, Jan Kara wrote:
>
> > Yeah, ionice has its limitations. The problem is that all buffered
> >writes happen just into memory (so completely independently of ionice
> >settings). Subsequent writing of dirty memory to disk happens using flusher
> >thread which is a kernel process and it doesn't know anything about IO
> >priority set for task which created the file. If you wrote the file with
> >oflag=direct or oflag=sync you would see that ionice works as expected.
>
> Has anyone looked at storing the ionice value with the buffered
> write request such that the actual writes to disk could be sorted by
> priority and done with the ionice level of the original caller?
There's nothing as "buffered write request" in kernel. When buffered
write happens, data are just copied into page cache. We could attach a tag
to each modified page in the page cache but that would get really expensive.
Essentially the same problems happens with cgroups where buffered writes
are not accounted as well. There we considered to attach a tag to inodes
(which doesn't work well if processes from different cgroups / with
different IO priority write to the same inode but that's not that common)
which is reasonably cheap. But then you have to build smarts into flusher
thread to prioritize inodes according to tags (you cannot really let
flusher thread just submit IO with that priority because when it gets
blocked, it starves writeback with possible higher priority). Alternatively
you could have separate flusher thread per-cgroup / IO priority. That is
easier from code point of view but throughput suffers because of limited
merging of IO. So all in all the problem is known but hard to tackle.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
prev parent reply other threads:[~2012-10-18 22:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0B138F62-16BF-4295-9AD9-64C0BB39FCE2@alex.org.uk>
[not found] ` <20121012133044.GA10115@dhcp22.suse.cz>
[not found] ` <E6EF14955C67D6CA58918872@nimrod.local>
[not found] ` <20121012145838.GD22083@dhcp22.suse.cz>
[not found] ` <3D1C85A52BB960B79E37AC30@nimrod.local>
2012-10-18 21:28 ` Local DoS through write heavy I/O on CFQ & Deadline Jan Kara
2012-10-18 22:13 ` Chris Friesen
2012-10-18 22:24 ` Jan Kara [this message]
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=20121018222449.GA19204@quack.suse.cz \
--to=jack@suse.cz \
--cc=alex@alex.org.uk \
--cc=chris.friesen@genband.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).