Re: [rfc] drm/ttm/memcg: simplest initial memcg/ttm integration (v2)

On Fri, May 02, 2025 at 01:35:59PM +1000, Dave Airlie wrote: > Hey all, > > This is my second attempt at adding the initial simple memcg/ttm > integration. > > This varies from the first attempt in two major ways: > > 1. Instead of using __GFP_ACCOUNT and direct calling kmem charges > for pool m

Re: [PATCHv3 06/11] mm/vmscan: Use PG_dropbehind instead of PG_reclaim

On Thu, Jan 30, 2025 at 12:00:44PM +0200, Kirill A. Shutemov wrote: > The recently introduced PG_dropbehind allows for freeing folios > immediately after writeback. Unlike PG_reclaim, it does not need vmscan > to be involved to get the folio freed. > > Instead of using folio_set_reclaim(), use fol

Re: [PATCHv3 02/11] drm/i915/gem: Convert __shmem_writeback() to folios

On Thu, Jan 30, 2025 at 12:00:40PM +0200, Kirill A. Shutemov wrote: > Use folios instead of pages. > > This is preparation for removing PG_reclaim. > > Signed-off-by: Kirill A. Shutemov > Acked-by: David Hildenbrand > --- > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 18 +- > 1

Re: [RFC PATCH 1/6] mm/page_counter: Move calculating protection values to page_counter

ent to the series. Acked-by: Shakeel Butt

Re: [net-next v1 01/16] net: page_pool: factor out releasing DMA from releasing the page

> Signed-off-by: Mina Almasry > Reviewed-by: Shakeel Butt

Re: [net-next v1 00/16] Device Memory TCP

On Thu, Dec 07, 2023 at 04:52:31PM -0800, Mina Almasry wrote: [...] > > Today, the majority of the Device-to-Device data transfers the network are 'the network' in above can be removed. > implemented as the following low level operations: Device-to-Host copy, > Host-to-Host network transfer, and

Re: [PATCH v2 1/4] memcg: Track exported dma-buffers

On Tue, Jan 24, 2023 at 03:59:58PM +0100, Michal Hocko wrote: > On Mon 23-01-23 19:17:23, T.J. Mercier wrote: > > When a buffer is exported to userspace, use memcg to attribute the > > buffer to the allocating cgroup until all buffer references are > > released. > > Is there any reason why this me

Re: [PATCH 0/4] Track exported dma-buffers with memcg

On Wed, Jan 11, 2023 at 04:49:36PM -0800, T.J. Mercier wrote: > [...] > > The problem is a bit that with gpu allocations reclaim is essentially "we > > pass the error to userspace and they get to sort the mess out". There are > > some exceptions (some gpu drivers to have shrinkers) would we need t

Re: [PATCH 0/4] Track exported dma-buffers with memcg

On Wed, Jan 11, 2023 at 11:56:45PM +0100, Daniel Vetter wrote: > [...] > I think eventually, at least for other "account gpu stuff in cgroups" use > case we do want to actually charge the memory. > > The problem is a bit that with gpu allocations reclaim is essentially "we > pass the error to use

Re: [PATCH 0/4] Track exported dma-buffers with memcg

Hi T.J., On Mon, Jan 9, 2023 at 1:38 PM T.J. Mercier wrote: > > Based on discussions at LPC, this series adds a memory.stat counter for > exported dmabufs. This counter allows us to continue tracking > system-wide total exported buffer sizes which there is no longer any > way to get without DMABU