a 10% improvement to build times is
achieved with this patch (there are a lot of symlinks in the source
tree).
Please provide feedback, I'm looking to flesh this out more.
Signed-off-by: Dan Schatzberg
---
fs/fuse/dir.c | 70 +++
1 file changed, 43
On 9/27/18, 9:59 AM, "Miklos Szeredi" wrote:
> On Thu, Sep 27, 2018 at 3:52 PM, Dan Schatzberg wrote:
>> FUSE file reads are cached in the page cache, but symlink reads are
>> not. This patch enables FUSE READLINK operations to be cached which
>> can improve per
On 10/16/18, 4:20 AM, "Miklos Szeredi" wrote:
>
> On Mon, Oct 15, 2018 at 8:47 PM, Stephen Rothwell
> wrote:
>> Hi Miklos,
>>
>> Commit
>>
>> 5571f1e65486 ("fuse: enable caching of symlinks")
>>
>> is missing a Signed-off-by from its author.
>
> Dan,
>
> Maybe you mistakenly left off the SOB t
FUSE file reads are cached in the page cache, but symlink reads are
not. This patch enables FUSE READLINK operations to be cached which
can improve performance of some FUSE workloads.
In particular, I'm working on a FUSE filesystem for access to source
code and discovered that about a 10% improvem
on/admin-guide/cgroup-v2.rst | 6 +++---
> kernel/cgroup/cgroup.c | 4 +++-
> 2 files changed, 6 insertions(+), 4 deletions(-)
Both patches look good.
Acked-by: Dan Schatzberg
On Thu, Mar 18, 2021 at 05:56:28PM -0700, Shakeel Butt wrote:
>
> We need something similar for mem_cgroup_swapin_charge_page() as well.
>
> It is better to take this series in mm tree and Jens is ok with that [1].
>
> [1]
> https://lore.kernel.org/linux-next/4fea89a5-0e18-0791-18a8-4c5907b0d..
On Thu, Mar 18, 2021 at 02:12:10PM -0600, Jens Axboe wrote:
> On 3/18/21 9:16 AM, Colin King wrote:
> > From: Colin Ian King
> >
> > The 3rd argument to alloc_workqueue should be the max_active count,
> > however currently it is the lo->lo_number that is intended for the
> > loop%d number. Fix th
On Thu, Mar 18, 2021 at 03:16:26PM +, Colin King wrote:
> From: Colin Ian King
>
> The 3rd argument to alloc_workqueue should be the max_active count,
> however currently it is the lo->lo_number that is intended for the
> loop%d number. Fix this by adding in the missing max_active count.
>
On Fri, Mar 19, 2021 at 09:20:16AM -0700, Shakeel Butt wrote:
> One suggestion would be to make get_mem_cgroup_from_mm() more generic
> (i.e. handle !mm && active_memcg() case) and avoid
> get_mem_cgroup_from_current() as it might go away.
Yeah, that occurred to me as well. I'll take a stab at doi
uot;)
> url:
> https://github.com/0day-ci/linux/commits/Dan-Schatzberg/Charge-loop-device-i-o-to-issuing-cgroup/20210316-233842
> base: https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git
> for-next
>
> in testcase: xfstests
> version: xfstests-x86_64-73c0871-
hat each cgroup can make
forward progress independently to avoid this inversion.
With this patch series applied, the above script triggers OOM kills
when writing through the loop device as expected.
Dan Schatzberg (3):
loop: Use worker per cgroup instead of kworker
mm: Charge activ
accessed. The existing
implementation serializes all I/O through a single thread anyways, so I
don't believe this is any worse.
Signed-off-by: Dan Schatzberg
---
drivers/block/loop.c | 207 ---
drivers/block/loop.h | 12 ++-
2 files changed, 182
as passed to mem_cgroup_try_charge (case 3) it
would always charge the root cgroup. Now it looks up the current
active_memcg first (falling back to charging the root cgroup if not
set).
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Acked-by: Chris Down
Reviewed-by: Shakeel B
and int_active_memcg so it
can be used by the loop module.
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
---
drivers/block/loop.c | 61 +-
drivers/block/loop.h | 3 +-
include/linux/memcontrol.h | 11 +++
kernel/cgroup/cgroup.c
In doing some memory trace analysis I've noticed a lack of a way to
disambiguate loads from stores in perf mem report. In order to address
this I've added the raw event name to the output.
Please let me know if there's some better way to achieve this instead.
Dan Schatzberg (1):
the
event name.
Signed-off-by: Dan Schatzberg
---
tools/perf/builtin-mem.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index cdd2b9f643f6..1f4ec350bca3 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf
On Tue, Mar 16, 2021 at 08:50:16AM -0700, Shakeel Butt wrote:
> You will need to rebase to the latest mm tree. This code has changed.
Thanks for the feedback, I will address these comments in another
rebase. I'll wait and see if there's any comments concerning the
loop-related patches but it sound
loop device. This patch series does some
minor modification to the loop driver so that each cgroup can make
forward progress independently to avoid this inversion.
With this patch series applied, the above script triggers OOM kills
when writing through the loop device as expected.
Dan Schatzberg (3
accessed. The existing
implementation serializes all I/O through a single thread anyways, so I
don't believe this is any worse.
Fixes-from: Colin Ian King
Signed-off-by: Dan Schatzberg
---
drivers/block/loop.c | 207 ---
drivers/block/loop.h | 12 ++
ase 3) it
would always charge the root cgroup. Now it looks up the active_memcg
first (falling back to charging the root cgroup if not set).
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Acked-by: Chris Down
Reviewed-by: Shakeel Butt
---
mm/filemap.c|
and int_active_memcg so it
can be used by the loop module.
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
---
drivers/block/loop.c | 61 +-
drivers/block/loop.h | 3 +-
include/linux/memcontrol.h | 6
kernel/cgroup/cgroup.c | 1
Hi Hillf, thanks for the review
On Sat, Apr 03, 2021 at 10:09:02AM +0800, Hillf Danton wrote:
> On Fri, 2 Apr 2021 12:16:32 Dan Schatzberg wrote:
> > +queue_work:
> > + if (worker) {
> > + /*
> > +* We need to remove fr
On Wed, Apr 07, 2021 at 02:53:00PM +0800, Hillf Danton wrote:
> On Tue, 6 Apr 2021 Dan Schatzberg wrote:
> >On Sat, Apr 03, 2021 at 10:09:02AM +0800, Hillf Danton wrote:
> >> On Fri, 2 Apr 2021 12:16:32 Dan Schatzberg wrote:
> >> > +queue_wo
ough
the single kworker thread in the case where multiple cgroups are
reading/writing to the same loop device. This patch series does some
minor modification to the loop driver so that each cgroup can make
forward progress independently to avoid this inversion.
With this patch series applied, th
accessed. The existing
implementation serializes all I/O through a single thread anyways, so I
don't believe this is any worse.
Fixes-from: Colin Ian King
Signed-off-by: Dan Schatzberg
---
drivers/block/loop.c | 203 ---
drivers/block/loop.h | 12 ++
ase 3) it
would always charge the root cgroup. Now it looks up the active_memcg
first (falling back to charging the root cgroup if not set).
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Acked-by: Chris Down
Reviewed-by: Shakeel Butt
---
mm/filemap.c|
and int_active_memcg so it
can be used by the loop module.
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
---
drivers/block/loop.c | 61 +-
drivers/block/loop.h | 3 +-
include/linux/memcontrol.h | 6
kernel/cgroup/cgroup.c | 1
his inversion.
With this patch series applied, the above script triggers OOM kills
when writing through the loop device as expected.
Dan Schatzberg (3):
loop: Use worker per cgroup instead of kworker
mm: Charge active memcg when no mm is set
loop: Charge i/o to mem and blk cg
Johannes
so it can be used by the loop
module.
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
---
drivers/block/loop.c | 61 +-
drivers/block/loop.h | 3 +-
include/linux/memcontrol.h | 6
kernel/cgroup/cgroup.c | 1 +
4 files changed
accessed. The existing
implementation serializes all I/O through a single thread anyways, so I
don't believe this is any worse.
Signed-off-by: Dan Schatzberg
---
drivers/block/loop.c | 207 ---
drivers/block/loop.h | 11 ++-
2 files changed, 180
From: Johannes Weiner
The memalloc_use_memcg() function to override the default memcg
accounting context currently doesn't nest. But the patches to make the
loop driver cgroup-aware will end up nesting:
[ 98.137605] alloc_page_buffers+0x210/0x288
[ 98.141799] __getblk_gfp+0x1d4/0x400
[ 9
as passed to mem_cgroup_try_charge (case 3) it
would always charge the root cgroup. Now it looks up the current
active_memcg first (falling back to charging the root cgroup if not
set).
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Acked-by: Chris Down
Reviewed-by: Shakeel B
On Wed, Apr 29, 2020 at 07:47:34AM +1000, Dave Chinner wrote:
> On Tue, Apr 28, 2020 at 12:13:46PM -0400, Dan Schatzberg wrote:
> > The loop device runs all i/o to the backing file on a separate kworker
> > thread which results in all i/o being charged to the root cgroup. This
&g
Pressure metrics are already recorded and exposed in procfs for the
entire system, but any tool which monitors cgroup pressure has to
special case the root cgroup to read from procfs. This patch exposes
the already recorded pressure metrics on the root cgroup.
Signed-off-by: Dan Schatzberg
On 9/27/18, 9:59 AM, "Miklos Szeredi" wrote:
> On Thu, Sep 27, 2018 at 3:52 PM, Dan Schatzberg wrote:
>> FUSE file reads are cached in the page cache, but symlink reads are
>> not. This patch enables FUSE READLINK operations to be cached which
>> can improve per
d in the case where multiple cgroups are
reading/writing to the same loop device. This patch series does some
minor modification to the loop driver so that each cgroup can make
forward progress independently to avoid this inversion.
With this patch series applied, the above script triggers OOM kil
as passed to mem_cgroup_try_charge (case 3) it
would always charge the root cgroup. Now it looks up the current
active_memcg first (falling back to charging the root cgroup if not
set).
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Acked-by: Chris Down
Reviewed-by: Shakeel B
accessed. The existing
implementation serializes all I/O through a single thread anyways, so I
don't believe this is any worse.
Signed-off-by: Dan Schatzberg
---
drivers/block/loop.c | 203 ---
drivers/block/loop.h | 12 ++-
2 files changed, 178
From: Johannes Weiner
The memalloc_use_memcg() function to override the default memcg
accounting context currently doesn't nest. But the patches to make the
loop driver cgroup-aware will end up nesting:
[ 98.137605] alloc_page_buffers+0x210/0x288
[ 98.141799] __getblk_gfp+0x1d4/0x400
[ 9
so it can be used by the loop
module.
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
---
drivers/block/loop.c | 61 +-
drivers/block/loop.h | 3 +-
include/linux/memcontrol.h | 6
kernel/cgroup/cgroup.c | 1 +
4 files changed
On Tue, May 12, 2020 at 06:35:45AM -0700, Christoph Hellwig wrote:
> 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 acro
on.
With this patch series applied, the above script triggers OOM kills
when writing through the loop device as expected.
Dan Schatzberg (3):
loop: Use worker per cgroup instead of kworker
mm: Charge active memcg when no mm is set
loop: Charge i/o to mem and blk cg
Johannes We
accessed. The existing
implementation serializes all I/O through a single thread anyways, so I
don't believe this is any worse.
Signed-off-by: Dan Schatzberg
---
drivers/block/loop.c | 207 ---
drivers/block/loop.h | 12 ++-
2 files changed, 182
so it can be used by the loop
module.
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
---
drivers/block/loop.c | 61 +-
drivers/block/loop.h | 3 +-
include/linux/memcontrol.h | 6
kernel/cgroup/cgroup.c | 1 +
mm/shmem.c
as passed to mem_cgroup_try_charge (case 3) it
would always charge the root cgroup. Now it looks up the current
active_memcg first (falling back to charging the root cgroup if not
set).
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Acked-by: Chris Down
Reviewed-by: Shakeel B
From: Johannes Weiner
The memalloc_use_memcg() function to override the default memcg
accounting context currently doesn't nest. But the patches to make the
loop driver cgroup-aware will end up nesting:
[ 98.137605] alloc_page_buffers+0x210/0x288
[ 98.141799] __getblk_gfp+0x1d4/0x400
[ 9
On Mon, Aug 24, 2020 at 09:19:01AM -0700, Roman Gushchin wrote:
> Hi Dan,
>
> JFYI: I need a similar patch for the bpf memory accounting rework,
> so I ended up sending it separately (with some modifications including
> different naming): https://lkml.org/lkml/2020/8/21/1464 .
>
> Can you please,
as passed to mem_cgroup_try_charge (case 3) it
would always charge the root cgroup. Now it looks up the current
active_memcg first (falling back to charging the root cgroup if not
set).
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Acked-by: Chris Down
Reviewed-by: Shakeel B
so it can be used by the loop
module.
Signed-off-by: Dan Schatzberg
Acked-by: Johannes Weiner
---
drivers/block/loop.c | 61 +-
drivers/block/loop.h | 3 +-
include/linux/memcontrol.h | 6
kernel/cgroup/cgroup.c | 1 +
4 files changed
accessed. The existing
implementation serializes all I/O through a single thread anyways, so I
don't believe this is any worse.
Signed-off-by: Dan Schatzberg
---
drivers/block/loop.c | 207 ---
drivers/block/loop.h | 12 ++-
2 files changed, 182
e
forward progress independently to avoid this inversion.
With this patch series applied, the above script triggers OOM kills
when writing through the loop device as expected.
Dan Schatzberg (3):
loop: Use worker per cgroup instead of kworker
mm: Charge active memcg when no mm is set
loop: Cha
On Thu, Aug 20, 2020 at 10:06:44AM -0700, Shakeel Butt wrote:
> On Thu, May 28, 2020 at 6:55 AM Dan Schatzberg
> wrote:
> >
> > Much of the discussion about this has died down. There's been a
> > concern raised that we could generalize infrastructure across l
Jens,
How would you like to resolve this patch series? Roman's patch that
this is based off of just made it into linux-next:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/928776957ea4e1c35b1c4c35b8fe7203354fbae3
I suppose you can pull that into the block tree and hav
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
54 matches
Mail list logo
