From: Alistair Popple <apopple@nvidia.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: 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, linuxppc-dev@lists.ozlabs.org, linux-fpga@vger.kernel.org, linux-rdma@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, netdev@vger.kernel.org, io-uring@vger.kernel.org, bpf@vger.kernel.org, rds-devel@oss.oracle.com, linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH 01/19] mm: Introduce vm_account Date: Mon, 30 Jan 2023 22:36:43 +1100 [thread overview] Message-ID: <87h6w8z1qr.fsf@nvidia.com> (raw) In-Reply-To: <Y8/r91PGGiY5JJvE@nvidia.com> Jason Gunthorpe <jgg@nvidia.com> writes: > On Tue, Jan 24, 2023 at 04:42:30PM +1100, Alistair Popple wrote: >> +/** >> + * enum vm_account_flags - Determine how pinned/locked memory is accounted. >> + * @VM_ACCOUNT_TASK: Account pinned memory to mm->pinned_vm. >> + * @VM_ACCOUNT_BYPASS: Don't enforce rlimit on any charges. >> + * @VM_ACCOUNT_USER: Accounnt locked memory to user->locked_vm. >> + * >> + * Determines which statistic pinned/locked memory is accounted >> + * against. All limits will be enforced against RLIMIT_MEMLOCK and the >> + * pins cgroup if CONFIG_CGROUP_PINS is enabled. >> + * >> + * New drivers should use VM_ACCOUNT_TASK. VM_ACCOUNT_USER is used by >> + * pre-existing drivers to maintain existing accounting against >> + * user->locked_mm rather than mm->pinned_mm. > > I thought the guidance was the opposite of this, it is the newer > places in the kernel that are using VM_ACCOUNT_USER? I'd just assumed mm->pinned_vm was preferred because that's what most drivers use. user->locked_mm does seem more sensible though as at least it's possible to meaningfully enforce some overall limit. Will switch the flags/comment around to suggest new users use VM_ACCOUNT_USER. > I haven't got to the rest of the patches yet, but isn't there also a > mm->pinned_vm vs mm->locked_vm variation in the current drivers as > well? > >> +void vm_account_init_current(struct vm_account *vm_account) >> +{ >> + vm_account_init(vm_account, current, NULL, VM_ACCOUNT_TASK); >> +} >> +EXPORT_SYMBOL_GPL(vm_account_init_current); > > This can probably just be a static inline > > You might consider putting all this in some new vm_account.h - given > how rarely it is used? Compile times and all Works for me. > Jason
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Popple <apopple@nvidia.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: rds-devel@oss.oracle.com, linux-kselftest@vger.kernel.org, kvm@vger.kernel.org, linux-rdma@vger.kernel.org, jhubbard@nvidia.com, linux-fpga@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, netdev@vger.kernel.org, mkoutny@suse.com, daniel@ffwll.ch, hannes@cmpxchg.org, cgroups@vger.kernel.org, bpf@vger.kernel.org, surenb@google.com, tjmercier@google.com, io-uring@vger.kernel.org Subject: Re: [RFC PATCH 01/19] mm: Introduce vm_account Date: Mon, 30 Jan 2023 22:36:43 +1100 [thread overview] Message-ID: <87h6w8z1qr.fsf@nvidia.com> (raw) In-Reply-To: <Y8/r91PGGiY5JJvE@nvidia.com> Jason Gunthorpe <jgg@nvidia.com> writes: > On Tue, Jan 24, 2023 at 04:42:30PM +1100, Alistair Popple wrote: >> +/** >> + * enum vm_account_flags - Determine how pinned/locked memory is accounted. >> + * @VM_ACCOUNT_TASK: Account pinned memory to mm->pinned_vm. >> + * @VM_ACCOUNT_BYPASS: Don't enforce rlimit on any charges. >> + * @VM_ACCOUNT_USER: Accounnt locked memory to user->locked_vm. >> + * >> + * Determines which statistic pinned/locked memory is accounted >> + * against. All limits will be enforced against RLIMIT_MEMLOCK and the >> + * pins cgroup if CONFIG_CGROUP_PINS is enabled. >> + * >> + * New drivers should use VM_ACCOUNT_TASK. VM_ACCOUNT_USER is used by >> + * pre-existing drivers to maintain existing accounting against >> + * user->locked_mm rather than mm->pinned_mm. > > I thought the guidance was the opposite of this, it is the newer > places in the kernel that are using VM_ACCOUNT_USER? I'd just assumed mm->pinned_vm was preferred because that's what most drivers use. user->locked_mm does seem more sensible though as at least it's possible to meaningfully enforce some overall limit. Will switch the flags/comment around to suggest new users use VM_ACCOUNT_USER. > I haven't got to the rest of the patches yet, but isn't there also a > mm->pinned_vm vs mm->locked_vm variation in the current drivers as > well? > >> +void vm_account_init_current(struct vm_account *vm_account) >> +{ >> + vm_account_init(vm_account, current, NULL, VM_ACCOUNT_TASK); >> +} >> +EXPORT_SYMBOL_GPL(vm_account_init_current); > > This can probably just be a static inline > > You might consider putting all this in some new vm_account.h - given > how rarely it is used? Compile times and all Works for me. > Jason
next prev parent reply other threads:[~2023-01-30 11:43 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-24 5:42 [RFC PATCH 00/19] mm: Introduce a cgroup to limit the amount of locked and pinned memory Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 01/19] mm: Introduce vm_account Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 6:29 ` Christoph Hellwig 2023-01-24 6:29 ` Christoph Hellwig 2023-01-24 6:29 ` Christoph Hellwig 2023-01-24 14:32 ` Jason Gunthorpe 2023-01-24 14:32 ` Jason Gunthorpe 2023-01-30 11:36 ` Alistair Popple [this message] 2023-01-30 11:36 ` Alistair Popple 2023-01-31 14:00 ` David Hildenbrand 2023-01-31 14:00 ` David Hildenbrand 2023-01-31 14:00 ` David Hildenbrand 2023-01-24 5:42 ` [RFC PATCH 02/19] drivers/vhost: Convert to use vm_account Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:55 ` Michael S. Tsirkin 2023-01-24 5:55 ` Michael S. Tsirkin 2023-01-24 5:55 ` Michael S. Tsirkin 2023-01-30 10:43 ` Alistair Popple 2023-01-30 10:43 ` Alistair Popple 2023-01-24 14:34 ` Jason Gunthorpe 2023-01-24 5:42 ` [RFC PATCH 03/19] drivers/vdpa: Convert vdpa to use the new vm_structure Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 14:35 ` Jason Gunthorpe 2023-01-24 14:35 ` Jason Gunthorpe 2023-01-24 5:42 ` [RFC PATCH 04/19] infiniband/umem: Convert to use vm_account Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 05/19] RMDA/siw: " Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 14:37 ` Jason Gunthorpe 2023-01-24 15:22 ` Bernard Metzler 2023-01-24 15:22 ` Bernard Metzler 2023-01-24 15:56 ` Bernard Metzler 2023-01-24 15:56 ` Bernard Metzler 2023-01-30 11:34 ` Alistair Popple 2023-01-30 11:34 ` Alistair Popple 2023-01-30 13:27 ` Bernard Metzler 2023-01-24 5:42 ` [RFC PATCH 06/19] RDMA/usnic: convert " Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 14:41 ` Jason Gunthorpe 2023-01-24 14:41 ` Jason Gunthorpe 2023-01-30 11:10 ` Alistair Popple 2023-01-30 11:10 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 07/19] vfio/type1: Charge pinned pages to pinned_vm instead of locked_vm Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 08/19] vfio/spapr_tce: Convert accounting to pinned_vm Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 09/19] io_uring: convert to use vm_account Alistair Popple 2023-01-24 14:44 ` Jason Gunthorpe 2023-01-30 11:12 ` Alistair Popple 2023-01-30 11:12 ` Alistair Popple 2023-01-30 13:21 ` Jason Gunthorpe 2023-01-24 5:42 ` [RFC PATCH 10/19] net: skb: Switch to using vm_account Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 14:51 ` Jason Gunthorpe 2023-01-24 14:51 ` Jason Gunthorpe 2023-01-30 11:17 ` Alistair Popple 2023-02-06 4:36 ` Alistair Popple 2023-02-06 4:36 ` Alistair Popple 2023-02-06 13:14 ` Jason Gunthorpe 2023-02-06 13:14 ` Jason Gunthorpe 2023-01-24 5:42 ` [RFC PATCH 11/19] xdp: convert to use vm_account Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 12/19] kvm/book3s_64_vio: Convert account_locked_vm() to vm_account_pinned() Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 13/19] fpga: dfl: afu: convert to use vm_account Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 14/19] mm: Introduce a cgroup for pinned memory Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 8:20 ` kernel test robot 2023-01-24 15:00 ` kernel test robot 2023-01-24 15:41 ` kernel test robot 2023-01-27 21:44 ` Tejun Heo 2023-01-27 21:44 ` Tejun Heo 2023-01-30 13:20 ` Jason Gunthorpe 2023-01-30 13:20 ` Jason Gunthorpe 2023-01-24 5:42 ` [RFC PATCH 15/19] mm/util: Extend vm_account to charge pages against the pin cgroup Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 16/19] mm/util: Refactor account_locked_vm Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 9:52 ` kernel test robot 2023-01-24 5:42 ` [RFC PATCH 17/19] mm: Convert mmap and mlock to use account_locked_vm Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 18/19] mm/mmap: Charge locked memory to pins cgroup Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 5:42 ` [RFC PATCH 19/19] selftests/vm: Add pins-cgroup selftest for mlock/mmap Alistair Popple 2023-01-24 5:42 ` Alistair Popple 2023-01-24 18:26 ` [RFC PATCH 00/19] mm: Introduce a cgroup to limit the amount of locked and pinned memory Yosry Ahmed 2023-01-24 18:26 ` Yosry Ahmed 2023-01-31 0:54 ` Alistair Popple 2023-01-31 0:54 ` Alistair Popple 2023-01-31 5:14 ` Yosry Ahmed 2023-01-31 5:14 ` Yosry Ahmed 2023-01-31 11:22 ` Alistair Popple 2023-01-31 11:22 ` Alistair Popple 2023-01-31 19:49 ` Yosry Ahmed 2023-01-31 19:49 ` Yosry Ahmed 2023-01-24 20:12 ` Jason Gunthorpe 2023-01-24 20:12 ` Jason Gunthorpe 2023-01-31 13:57 ` David Hildenbrand 2023-01-31 14:03 ` Jason Gunthorpe 2023-01-31 14:03 ` Jason Gunthorpe 2023-01-31 14:06 ` David Hildenbrand 2023-01-31 14:10 ` Jason Gunthorpe 2023-01-31 14:10 ` Jason Gunthorpe 2023-01-31 14:15 ` David Hildenbrand 2023-01-31 14:15 ` David Hildenbrand 2023-01-31 14:21 ` Jason Gunthorpe
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=87h6w8z1qr.fsf@nvidia.com \ --to=apopple@nvidia.com \ --cc=bpf@vger.kernel.org \ --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=kvm@vger.kernel.org \ --cc=linux-fpga@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mkoutny@suse.com \ --cc=netdev@vger.kernel.org \ --cc=rds-devel@oss.oracle.com \ --cc=surenb@google.com \ --cc=tjmercier@google.com \ --cc=virtualization@lists.linux-foundation.org \ /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: linkBe 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.