Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1165606 > unrolled thread

Re: [PATCH 3/3] writeback, blkio: add documentation for cgroup writeback support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3/3] writeback, blkio: add documentation for cgroup  writeback support Theodore Ts'o <tytso@mit.edu> - 2015-06-16 01:40 +0200
    Re: [PATCH 3/3] writeback, blkio: add documentation for cgroup  writeback support Tejun Heo <tj@kernel.org> - 2015-06-17 00:00 +0200
      Re: [PATCH 3/3] writeback, blkio: add documentation for cgroup  writeback support Theodore Ts'o <tytso@mit.edu> - 2015-06-17 23:50 +0200

#1165606 — Re: [PATCH 3/3] writeback, blkio: add documentation for cgroup writeback support

On Mon, Jun 15, 2015 at 02:23:45PM -0400, Tejun Heo wrote:
> 
> On ext2, there's nothing interlocking each other.  My understanding of
> ext4 is pretty limited but as long as the journal head doesn't
> overwrap and gets bloked on the slow one, it should be fine, so for
> most use cases, this shouldn't be a problem.

The writes to the journal in ext3/ext4 are done from the jbd/jbd2
kernel thread.  So writes to the journal shouldn't be a problem.  In
data=ordered mode inodes that have blocks that were allocated during
the current transaction do have to have their data blocks written out,
and this is done by the jbd/jbd2 thread using filemap_fdatawait().

If this gets throttled because blocks were originally dirtied by some
cgroup that didn't have much disk time quota, then all file system
activities will get stalled out until the ordered mode writeback
completes, which means if there are any high priority cgroups trying
to execute any system call that mutates file system state will block
until the commit has gotten past the initial setup stage, and so other
system activity could sputter to a halt --- at which point the commit
will be allowed to compete, and then all of the calls to
ext4_journal_start() will unblock, and the system will come back to
life.  :-)

Because ext3 doesn't have delayed allocation, it will orders of
magnitude more data=ordered block flushing, so this problem will be
far worse with ext3 compared to ext4.

So if there is some way we can signal to any cgroup that that might be
throttling writeback or disk I/O that the jbd/jbd2 process should be
considered privileged, that would be a good since it would allow us to
avoid a potential priority inversion problem. 

						- Ted
--
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/

[toc] | [next] | [standalone]

#1166439

Hello, Ted.

On Mon, Jun 15, 2015 at 07:35:19PM -0400, Theodore Ts'o wrote:
> So if there is some way we can signal to any cgroup that that might be
> throttling writeback or disk I/O that the jbd/jbd2 process should be
> considered privileged, that would be a good since it would allow us to
> avoid a potential priority inversion problem. 

I see.  In the long term, I think we might need to come up with a way
to overcharge a slower cgroup to avoid blocking faster ones for cases
where some IOs are depended upon by more than one cgroups.  That'd
take quite a bit of work from blkcg side.  Will think more about it.

Thanks.

-- 
tejun
--
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/

[toc] | [prev] | [next] | [standalone]

#1167170

On Wed, Jun 17, 2015 at 02:52:37PM -0400, Tejun Heo wrote:
> 
> Hmmm... so, overriding things *before* an bio is issued shouldn't be
> too difficult and as long as this sort of operations aren't prevalent
> we might be able to get away with just charging them against root.
> Especially if it's to avoid getting blocked on the journal which we
> already consider a shared overhead which is charged to root.  If this
> becomes large enough to require exacting charges, it'll be more
> complex but still way better than trying to raise priority on a bio
> which is already issued, which is likely to be excruciatingly painful
> if possible at all.

Yeah, just charging the overhead to root seems good enough.

I could imagine charging it to whatever cgroup the jbd/jbd2 thread
belongs to, which in turn would be the cgroup of the process that
mounted the file system.  The only problem with that is that if a
low-priority process is allowed to mount a file system, and it gets
traversed by a high priority process, the high priority process will
get impacted.  So maybe it's better to just say that it always get
charged to the root cgroup.

					- Ted
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web