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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150620200010.GA16686@mtj.duckdns.org>
Date:	Sat, 20 Jun 2015 16:00:10 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Theodore Ts'o <tytso@....edu>, Vivek Goyal <vgoyal@...hat.com>,
	axboe@...nel.dk, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, lizefan@...wei.com,
	cgroups@...r.kernel.org
Subject: Re: [PATCH 3/3] writeback, blkio: add documentation for cgroup
 writeback support

Hey, Ted.

On Wed, Jun 17, 2015 at 05:48:52PM -0400, Theodore Ts'o wrote:
> 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 think the easiest way to achieve this bypass would be making jbd
mark the inode while waiting in fdatawait so that writeback path can
skip attaching the writeback bios for the inode.  This isn't perfect
but should be able to work around stalls from priority inversion to
certain extent.

However, I can't come up with a workload to test it.  AFAICS, the
fdatawait stall path in jbd2 is journal_finish_inode_data_buffers()
but the path doesn't trigger reliabley with mixed load of overwriting
dd, a bunch of file creations and chmods and different cgroups stay
pretty well isolated.

Can you please suggest a workload for testing the datawait path?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/