From: Christoph Hellwig <hch@infradead.org>
To: Dan Schatzberg <schatzberg.dan@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Amir Goldstein <amir73il@gmail.com>, Tejun Heo <tj@kernel.org>,
Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Roman Gushchin <guro@fb.com>,
Shakeel Butt <shakeelb@google.com>,
Chris Down <chris@chrisdown.name>,
Yang Shi <yang.shi@linux.alibaba.com>,
Ingo Molnar <mingo@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Thomas
Subject: Re: [PATCH v5 0/4] Charge loop device i/o to issuing cgroup
Date: Tue, 12 May 2020 06:35:45 -0700 [thread overview]
Message-ID: <20200512133545.GA26535@infradead.org> (raw)
In-Reply-To: <20200512132521.GA28700@dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com>
On Tue, May 12, 2020 at 09:25:21AM -0400, Dan Schatzberg wrote:
> Seems like discussion on this patch series has died down. There's been
> a concern raised that we could generalize infrastructure across loop,
> md, etc. This may be possible, in the future, but it isn't clear to me
> how this would look like. I'm inclined to fix the existing issue with
> loop devices now (this is a problem we hit at FB) and address
> consolidation with other cases if and when those are addressed.
>
> Jens, you've expressed interest in seeing this series go through the
> block tree so I'm interested in your perspective here. Barring any
> concrete implementation bugs, would you be okay merging this version?
Independ of any higher level issues you need to sort out the spinlock
mess I pointed out.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Dan Schatzberg <schatzberg.dan@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Amir Goldstein <amir73il@gmail.com>, Tejun Heo <tj@kernel.org>,
Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Roman Gushchin <guro@fb.com>,
Shakeel Butt <shakeelb@google.com>,
Chris Down <chris@chrisdown.name>,
Yang Shi <yang.shi@linux.alibaba.com>,
Ingo Molnar <mingo@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"open list:BLOCK LAYER" <linux-block@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:FILESYSTEMS (VFS and infrastructure)"
<linux-fsdevel@vger.kernel.org>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<linux-mm@kvack.org>
Subject: Re: [PATCH v5 0/4] Charge loop device i/o to issuing cgroup
Date: Tue, 12 May 2020 06:35:45 -0700 [thread overview]
Message-ID: <20200512133545.GA26535@infradead.org> (raw)
In-Reply-To: <20200512132521.GA28700@dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com>
On Tue, May 12, 2020 at 09:25:21AM -0400, Dan Schatzberg wrote:
> Seems like discussion on this patch series has died down. There's been
> a concern raised that we could generalize infrastructure across loop,
> md, etc. This may be possible, in the future, but it isn't clear to me
> how this would look like. I'm inclined to fix the existing issue with
> loop devices now (this is a problem we hit at FB) and address
> consolidation with other cases if and when those are addressed.
>
> Jens, you've expressed interest in seeing this series go through the
> block tree so I'm interested in your perspective here. Barring any
> concrete implementation bugs, would you be okay merging this version?
Independ of any higher level issues you need to sort out the spinlock
mess I pointed out.
next prev parent reply other threads:[~2020-05-12 13:35 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 16:13 [PATCH v5 0/4] Charge loop device i/o to issuing cgroup Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` [PATCH v5 1/4] loop: Use worker per cgroup instead of kworker Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` [PATCH v5 2/4] mm: support nesting memalloc_use_memcg() Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` [PATCH v5 3/4] mm: Charge active memcg when no mm is set Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` [PATCH v5 4/4] loop: Charge i/o to mem and blk cg Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
2020-04-28 16:13 ` Dan Schatzberg
[not found] ` <20200428161355.6377-1-schatzberg.dan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-28 21:47 ` [PATCH v5 0/4] Charge loop device i/o to issuing cgroup Dave Chinner
2020-04-28 21:47 ` Dave Chinner
[not found] ` <20200428214653.GD2005-pA1nmv6sEBkOM8BvhN4Z8vybgvtCy99p@public.gmane.org>
2020-04-29 2:27 ` Johannes Weiner
2020-04-29 2:27 ` Johannes Weiner
[not found] ` <20200429022732.GA401038-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-05-05 6:29 ` Dave Chinner
2020-05-05 6:29 ` Dave Chinner
[not found] ` <20200505062946.GH2005-pA1nmv6sEBkOM8BvhN4Z8vybgvtCy99p@public.gmane.org>
2020-05-05 13:55 ` Shakeel Butt
2020-05-05 13:55 ` Shakeel Butt
2020-05-05 15:02 ` Johannes Weiner
2020-05-05 15:02 ` Johannes Weiner
2020-04-29 10:25 ` Jan Kara
2020-04-29 10:25 ` Jan Kara
2020-04-29 14:22 ` Tejun Heo
2020-04-29 14:22 ` Tejun Heo
[not found] ` <20200429142230.GE5462-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-04-29 16:21 ` Jan Kara
2020-04-29 16:21 ` Jan Kara
2020-05-05 6:41 ` Dave Chinner
2020-05-05 6:41 ` Dave Chinner
[not found] ` <20200505064114.GI2005-pA1nmv6sEBkOM8BvhN4Z8vybgvtCy99p@public.gmane.org>
2020-05-05 15:38 ` Tejun Heo
2020-05-05 15:38 ` Tejun Heo
2020-04-29 14:03 ` Dan Schatzberg
2020-04-29 14:03 ` Dan Schatzberg
2020-05-12 13:25 ` Dan Schatzberg
2020-05-12 13:25 ` Dan Schatzberg
2020-05-12 13:35 ` Christoph Hellwig [this message]
2020-05-12 13:35 ` Christoph Hellwig
2020-05-26 14:28 ` Dan Schatzberg
2020-05-26 14:28 ` Dan Schatzberg
[not found] ` <20200526142803.GA1061-fkkBeQb8ge2DK6JXYb2XlJM2KBzDZLgSYRRNvcr/Vuo4Aut8bSbYrdcQFCl+OI4i@public.gmane.org>
2020-05-27 5:09 ` Christoph Hellwig
2020-05-27 5:09 ` Christoph Hellwig
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=20200512133545.GA26535@infradead.org \
--to=hch@infradead.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=axboe@kernel.dk \
--cc=chris@chrisdown.name \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=lizefan@huawei.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhocko@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=schatzberg.dan@gmail.com \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yang.shi@linux.alibaba.com \
/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.