linux-kernel - Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Nov 2017 12:34:58 -0500
From:   Chris Mason <clm@...com>
To:     <dsterba@...e.cz>, Tejun Heo <tj@...nel.org>,
        Jan Kara <jack@...e.cz>, <axboe@...nel.dk>, <jbacik@...com>,
        <kernel-team@...com>, <linux-kernel@...r.kernel.org>,
        <linux-btrfs@...r.kernel.org>
Subject: Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues
 metadata IOs from the root cgroup



On 11/30/2017 12:23 PM, David Sterba wrote:
> On Wed, Nov 29, 2017 at 01:38:26PM -0500, Chris Mason wrote:
>> On 11/29/2017 12:05 PM, Tejun Heo wrote:
>>> On Wed, Nov 29, 2017 at 09:03:30AM -0800, Tejun Heo wrote:
>>>> Hello,
>>>>
>>>> On Wed, Nov 29, 2017 at 05:56:08PM +0100, Jan Kara wrote:
>>>>> What has happened with this patch set?
>>>>
>>>> No idea.  cc'ing Chris directly.  Chris, if the patchset looks good,
>>>> can you please route them through the btrfs tree?
>>>
>>> lol looking at the patchset again, I'm not sure that's obviously the
>>> right tree.  It can either be cgroup, block or btrfs.  If no one
>>> objects, I'll just route them through cgroup.
>>
>> We'll have to coordinate a bit during the next merge window but I don't
>> have a problem with these going in through cgroup.  Dave does this sound
>> good to you?
> 
> There are only minor changes to btrfs code so cgroup tree would be
> better.
> 
>> I'd like to include my patch to do all crcs inline (instead of handing
>> off to helper threads) when io controls are in place.  By the merge
>> window we should have some good data on how much it's all helping.
> 
> Are there any problems in sight if the inline crc and cgroup chnanges go
> separately? I assume there's a runtime dependency, not a code
> dependency, so it could be sorted by the right merge order.
> 

The feature is just more useful with the inline crcs.  Without them we 
end up with kworkers doing both high and low prio submissions and it all 
boils down to the speed of the lowest priority.

-chris