From: Alistair Popple <apopple@nvidia.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, jhubbard@nvidia.com,
tjmercier@google.com, hannes@cmpxchg.org, surenb@google.com,
mkoutny@suse.com, daniel@ffwll.ch,
"Daniel P . Berrange" <berrange@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Pavel Begunkov <asml.silence@gmail.com>,
io-uring@vger.kernel.org
Subject: Re: [PATCH 09/19] io_uring: convert to use vm_account
Date: Mon, 13 Feb 2023 22:30:42 +1100 [thread overview]
Message-ID: <87edqt243d.fsf@nvidia.com> (raw)
In-Reply-To: <53816439-6473-1c4f-2134-02cd1c46cfe8@kernel.dk>
Jens Axboe <axboe@kernel.dk> writes:
> On 2/7/23 7:55?AM, Jason Gunthorpe wrote:
>> On Tue, Feb 07, 2023 at 07:28:56AM -0700, Jens Axboe wrote:
>>
>>> Outside of that, we're now doubling the amount of memory associated with
>>> tracking this. That isn't necessarily a showstopper, but it is not
>>> ideal. I didn't take a look at the other conversions (again, because
>>> they were not sent to me), but seems like the task_struct and flags
>>> could just be passed in as they may very well be known to many/most
>>> callers?
>>
>> For places doing the mm accounting type it cannot use the task struct
>> as the underlying mm can be replaced and keep the task, IIRC.
>>
>> We just had a bug in VFIO related to this..
>>
>> If we could go back from the mm to the task (even a from a destroyed
>> mm though) that might work to reduce storage?
Yes, it's the going back from a destroyed mm that gets a bit murky. I
don't think it's a showstopper as we could probably keep track of that
when we destroy the mm but it seems like a fair amount of complexity to
save a smallish amount of memory.
However if we end up tacking this onto memcg instead then we could use
that to go back to the task and move any charges when the mm moves.
> Then maybe just nest them:
>
> struct small_one {
> struct mm_struct *mm;
> struct user_struct *user;
> };
>
> struct big_one {
> struct small_one foo;
> struct task_struct *task;
> enum vm_account_flags flags;
> };
>
> and have the real helpers deal with small_one, and wrappers around that
> taking big_one that just passes in the missing bits. Then users that
> don't need the extra bits can just use the right API.
Thanks for the suggestion, it should work noting that we will have to
add a struct pins_cgroup pointer to struct small_one. It may also help
with a similar problem I was having with one of the networking
conversions.
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
Cc: Jason Gunthorpe <jgg-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jhubbard-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org,
surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
mkoutny-IBi9RG/b67k@public.gmane.org,
daniel-/w4YWyX8dFk@public.gmane.org,
"Daniel P . Berrange"
<berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Pavel Begunkov
<asml.silence-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
io-uring-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 09/19] io_uring: convert to use vm_account
Date: Mon, 13 Feb 2023 22:30:42 +1100 [thread overview]
Message-ID: <87edqt243d.fsf@nvidia.com> (raw)
In-Reply-To: <53816439-6473-1c4f-2134-02cd1c46cfe8-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org> writes:
> On 2/7/23 7:55?AM, Jason Gunthorpe wrote:
>> On Tue, Feb 07, 2023 at 07:28:56AM -0700, Jens Axboe wrote:
>>
>>> Outside of that, we're now doubling the amount of memory associated with
>>> tracking this. That isn't necessarily a showstopper, but it is not
>>> ideal. I didn't take a look at the other conversions (again, because
>>> they were not sent to me), but seems like the task_struct and flags
>>> could just be passed in as they may very well be known to many/most
>>> callers?
>>
>> For places doing the mm accounting type it cannot use the task struct
>> as the underlying mm can be replaced and keep the task, IIRC.
>>
>> We just had a bug in VFIO related to this..
>>
>> If we could go back from the mm to the task (even a from a destroyed
>> mm though) that might work to reduce storage?
Yes, it's the going back from a destroyed mm that gets a bit murky. I
don't think it's a showstopper as we could probably keep track of that
when we destroy the mm but it seems like a fair amount of complexity to
save a smallish amount of memory.
However if we end up tacking this onto memcg instead then we could use
that to go back to the task and move any charges when the mm moves.
> Then maybe just nest them:
>
> struct small_one {
> struct mm_struct *mm;
> struct user_struct *user;
> };
>
> struct big_one {
> struct small_one foo;
> struct task_struct *task;
> enum vm_account_flags flags;
> };
>
> and have the real helpers deal with small_one, and wrappers around that
> taking big_one that just passes in the missing bits. Then users that
> don't need the extra bits can just use the right API.
Thanks for the suggestion, it should work noting that we will have to
add a struct pins_cgroup pointer to struct small_one. It may also help
with a similar problem I was having with one of the networking
conversions.
next prev parent reply other threads:[~2023-02-13 11:32 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-06 7:47 [PATCH 00/19] mm: Introduce a cgroup to limit the amount of locked and pinned memory Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 01/19] mm: Introduce vm_account Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 02/19] drivers/vhost: Convert to use vm_account Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 03/19] drivers/vdpa: Convert vdpa to use the new vm_structure Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 04/19] infiniband/umem: Convert to use vm_account Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 05/19] RMDA/siw: " Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-12 17:32 ` Bernard Metzler
2023-02-06 7:47 ` [PATCH 06/19] RDMA/usnic: convert " Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 07/19] vfio/type1: Charge pinned pages to pinned_vm instead of locked_vm Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 08/19] vfio/spapr_tce: Convert accounting to pinned_vm Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 09/19] io_uring: convert to use vm_account Alistair Popple
2023-02-06 15:29 ` Jens Axboe
2023-02-06 15:29 ` Jens Axboe
2023-02-07 1:03 ` Alistair Popple
2023-02-07 1:03 ` Alistair Popple
2023-02-07 14:28 ` Jens Axboe
2023-02-07 14:55 ` Jason Gunthorpe
2023-02-07 14:55 ` Jason Gunthorpe
2023-02-07 17:05 ` Jens Axboe
2023-02-07 17:05 ` Jens Axboe
2023-02-13 11:30 ` Alistair Popple [this message]
2023-02-13 11:30 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 10/19] net: skb: Switch to using vm_account Alistair Popple
2023-02-06 7:47 ` [PATCH 11/19] xdp: convert to use vm_account Alistair Popple
2023-02-06 7:47 ` [PATCH 12/19] kvm/book3s_64_vio: Convert account_locked_vm() to vm_account_pinned() Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 13/19] fpga: dfl: afu: convert to use vm_account Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 14/19] mm: Introduce a cgroup for pinned memory Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 21:01 ` Yosry Ahmed
2023-02-06 21:01 ` Yosry Ahmed
2023-02-06 21:14 ` Tejun Heo
2023-02-06 21:14 ` Tejun Heo
2023-02-06 22:32 ` Yosry Ahmed
2023-02-06 22:32 ` Yosry Ahmed
2023-02-06 22:36 ` Tejun Heo
2023-02-06 22:39 ` Yosry Ahmed
2023-02-06 22:39 ` Yosry Ahmed
2023-02-06 23:25 ` Tejun Heo
2023-02-06 23:25 ` Tejun Heo
2023-02-06 23:34 ` Yosry Ahmed
2023-02-06 23:34 ` Yosry Ahmed
2023-02-06 23:40 ` Jason Gunthorpe
2023-02-06 23:40 ` Jason Gunthorpe
2023-02-07 0:32 ` Tejun Heo
2023-02-07 0:32 ` Tejun Heo
2023-02-07 12:19 ` Jason Gunthorpe
2023-02-07 12:19 ` Jason Gunthorpe
2023-02-15 19:00 ` Michal Hocko
2023-02-15 19:00 ` Michal Hocko
2023-02-15 19:07 ` Jason Gunthorpe
2023-02-15 19:07 ` Jason Gunthorpe
2023-02-16 8:04 ` Michal Hocko
2023-02-16 8:04 ` Michal Hocko
2023-02-16 12:45 ` Jason Gunthorpe
2023-02-16 12:45 ` Jason Gunthorpe
2023-02-21 16:51 ` Tejun Heo
2023-02-21 16:51 ` Tejun Heo
2023-02-21 17:25 ` Jason Gunthorpe
2023-02-21 17:29 ` Tejun Heo
2023-02-21 17:29 ` Tejun Heo
2023-02-21 17:51 ` Jason Gunthorpe
2023-02-21 17:51 ` Jason Gunthorpe
2023-02-21 18:07 ` Tejun Heo
2023-02-21 18:07 ` Tejun Heo
2023-02-21 19:26 ` Jason Gunthorpe
2023-02-21 19:26 ` Jason Gunthorpe
2023-02-21 19:45 ` Tejun Heo
2023-02-21 19:45 ` Tejun Heo
2023-02-21 19:49 ` Tejun Heo
2023-02-21 19:49 ` Tejun Heo
2023-02-21 19:57 ` Jason Gunthorpe
2023-02-22 11:38 ` Alistair Popple
2023-02-22 11:38 ` Alistair Popple
2023-02-22 12:57 ` Jason Gunthorpe
2023-02-22 12:57 ` Jason Gunthorpe
2023-02-22 22:59 ` Alistair Popple
2023-02-22 22:59 ` Alistair Popple
2023-02-23 0:05 ` Christoph Hellwig
2023-02-23 0:35 ` Alistair Popple
2023-02-23 0:35 ` Alistair Popple
2023-02-23 1:53 ` Jason Gunthorpe
2023-02-23 1:53 ` Jason Gunthorpe
2023-02-23 9:12 ` Daniel P. Berrangé
2023-02-23 17:31 ` Jason Gunthorpe
2023-02-23 17:31 ` Jason Gunthorpe
2023-02-23 17:18 ` T.J. Mercier
2023-02-23 17:28 ` Jason Gunthorpe
2023-02-23 17:28 ` Jason Gunthorpe
2023-02-23 18:03 ` Yosry Ahmed
2023-02-23 18:10 ` Jason Gunthorpe
2023-02-23 18:10 ` Jason Gunthorpe
2023-02-23 18:14 ` Yosry Ahmed
2023-02-23 18:14 ` Yosry Ahmed
2023-02-23 18:15 ` Tejun Heo
2023-02-23 18:17 ` Jason Gunthorpe
2023-02-23 18:17 ` Jason Gunthorpe
2023-02-23 18:22 ` Tejun Heo
2023-02-23 18:22 ` Tejun Heo
2023-02-07 1:00 ` Waiman Long
2023-02-07 1:00 ` Waiman Long
2023-02-07 1:03 ` Tejun Heo
2023-02-07 1:50 ` Alistair Popple
2023-02-07 1:50 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 15/19] mm/util: Extend vm_account to charge pages against the pin cgroup Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 16/19] mm/util: Refactor account_locked_vm Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 17/19] mm: Convert mmap and mlock to use account_locked_vm Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 7:47 ` [PATCH 18/19] mm/mmap: Charge locked memory to pins cgroup Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-06 21:12 ` Yosry Ahmed
2023-02-06 7:47 ` [PATCH 19/19] selftests/vm: Add pins-cgroup selftest for mlock/mmap Alistair Popple
2023-02-06 7:47 ` Alistair Popple
2023-02-16 11:01 ` [PATCH 00/19] mm: Introduce a cgroup to limit the amount of locked and pinned memory David Hildenbrand
2023-02-16 11:01 ` David Hildenbrand
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=87edqt243d.fsf@nvidia.com \
--to=apopple@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=berrange@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=daniel@ffwll.ch \
--cc=hannes@cmpxchg.org \
--cc=io-uring@vger.kernel.org \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mkoutny@suse.com \
--cc=surenb@google.com \
--cc=tjmercier@google.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.