Re: [Intel-gfx] [PATCH] x86: Mark up large pm4/5 constants with UL

On Sun, Apr 29, 2018 at 12:48:32PM +0100, Chris Wilson wrote: > To silence sparse while maintaining compatibility with the assembly, use > _UL which conditionally only appends the UL suffix for C code. http://lkml.kernel.org/r/nycvar.yfh.7.76.1804121437350.28...@cbobk.fhfr.pm -- Ki

Re: [Intel-gfx] [PATCH] shmem: fix pageflags after swapping DMA32 object

nel.org # v4.8 > Signed-off-by: Hugh Dickins Sorry for that. Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] shmem: Support for registration of driver/file owner specific ops

ignorance, but shouldn't this kind of flushing be done in response to mmu_notifier's ->invalidate_page? I'm not aware about how i915 works and what's its expectation wrt shmem. Do you have some userspace VMA which is mirrored on GPU side? If yes, m

Re: [Intel-gfx] [PATCH v4 1/2] shmem: Support for registration of driver/file owner specific ops

On Tue, Apr 26, 2016 at 02:53:41PM +0200, Daniel Vetter wrote: > On Mon, Apr 25, 2016 at 02:42:50AM +0300, Kirill A. Shutemov wrote: > > On Mon, Apr 04, 2016 at 02:18:10PM +0100, Chris Wilson wrote: > > > From: Akash Goel > > > > > > This provides support for

Re: [Intel-gfx] [PATCH 06/17] mm/shmem: expose driver overridable huge option

up fadvise handle to control per-file allocation policy. -- Kirill A. Shutemov ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/21] mm/shmem: introduce shmem_file_setup_with_mnt

n version of __shmem_file_setup, it would be preferred if we could > just give shmem our mnt, and let it do the rest. > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Dave Hansen > Cc: Kirill A. Shutemov > Cc: Hugh Dickins > Cc: linux...

Re: [Intel-gfx] [PATCH 1/2] mm: Report attempts to overwrite PTE from remap_pfn_range()

Chris Wilson wrote: > When using remap_pfn_range() from a fault handler, we are exposed to > races between concurrent faults. Rather than hitting a BUG, report the > error back to the caller, like vm_insert_pfn(). > > Signed-off-by: Chris Wilson > Cc: Andrew Morton > Cc

Re: [Intel-gfx] [PATCH] mm: Report attempts to overwrite PTE from remap_pfn_range()

gt; v3: Report the error back and cleanup partial remaps. > > Signed-off-by: Chris Wilson > Cc: Andrew Morton > Cc: "Kirill A. Shutemov" > Cc: Peter Zijlstra > Cc: Rik van Riel > Cc: Mel Gorman > Cc: Cyrill Gorcunov > Cc: Johannes Weiner > Cc: linux...

Re: [Intel-gfx] [PATCH] mm: Report attempts to overwrite PTE from remap_pfn_range()

Chris Wilson wrote: > On Thu, Jun 19, 2014 at 02:50:18PM +0300, Kirill A. Shutemov wrote: > > > + if (err) { > > > untrack_pfn(vma, pfn, PAGE_ALIGN(size)); > > > + if (err != -EBUSY) > > > + zap_page_range_single(vma, addr,

Re: [Intel-gfx] [PATCH] mm: Report attempts to overwrite PTE from remap_pfn_range()

Chris Wilson wrote: > On Thu, Jun 19, 2014 at 03:57:46PM +0300, Kirill A. Shutemov wrote: > > One possible option is to create a variant of remap_pfn_range() which will > > return how many PTEs it was able to setup, before hitting the !pte_none(). > > Caller will decide what

Re: [Intel-gfx] [PATCH 1/4] mm: Refactor remap_pfn_range()

gned-off-by: Chris Wilson > Cc: Andrew Morton > Cc: "Kirill A. Shutemov" > Cc: Peter Zijlstra > Cc: Rik van Riel > Cc: Mel Gorman > Cc: Cyrill Gorcunov > Cc: Johannes Weiner > Cc: linux...@kvack.org > --- > mm/memory.c | 102 > +

Re: [Intel-gfx] [PATCH 3/4] mm: Export remap_io_mapping()

d-off-by: Chris Wilson Looks okay to me: Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

On Sat, Feb 01, 2025 at 04:01:43PM +0800, Kairui Song wrote: > On Thu, Jan 30, 2025 at 6:02 PM Kirill A. Shutemov > wrote: > > > > The recently introduced PG_dropbehind allows for freeing folios > > immediately after writeback. Unlike PG_reclaim, it does not need vmscan &

Re: [PATCH 0/8] mm: Remove PG_reclaim

On Mon, Jan 13, 2025 at 01:45:48PM +, Matthew Wilcox wrote: > On Mon, Jan 13, 2025 at 11:34:45AM +0200, Kirill A. Shutemov wrote: > > Use PG_dropbehind instead of PG_reclaim and remove PG_reclaim. > > I was hoping we'd end up with the name PG_reclaim instead of the

Re: [PATCH 4/8] mm/swap: Use PG_dropbehind instead of PG_reclaim

On Mon, Jan 13, 2025 at 08:17:20AM -0800, Yosry Ahmed wrote: > On Mon, Jan 13, 2025 at 1:35 AM Kirill A. Shutemov > wrote: > > > > The recently introduced PG_dropbehind allows for freeing folios > > immediately after writeback. Unlike PG_reclaim, it does not need vmscan &

Re: [PATCH 8/8] mm: Remove PG_reclaim

On Mon, Jan 13, 2025 at 03:28:43PM +, Matthew Wilcox wrote: > On Mon, Jan 13, 2025 at 11:34:53AM +0200, Kirill A. Shutemov wrote: > > diff --git a/mm/migrate.c b/mm/migrate.c > > index caadbe393aa2..beba72da5e33 100644 > > --- a/mm/migrate.c > > +++ b/mm/migrate.c &

Re: [PATCHv2 05/11] mm/truncate: Use folio_set_dropbehind() instead of deactivate_file_folio()k

On Wed, Jan 15, 2025 at 02:46:44PM -0700, Yu Zhao wrote: > On Wed, Jan 15, 2025 at 2:35 PM Matthew Wilcox wrote: > > > > On Wed, Jan 15, 2025 at 11:31:29AM +0200, Kirill A. Shutemov wrote: > > > -static void lru_deactivate_file(struct lruvec *lruvec, st

Re: [PATCHv2 11/11] mm: Rename PG_dropbehind to PG_reclaim

On Wed, Jan 15, 2025 at 10:18:16PM -0800, Christoph Hellwig wrote: > On Wed, Jan 15, 2025 at 11:31:35AM +0200, Kirill A. Shutemov wrote: > > Now as PG_reclaim is gone, its name can be reclaimed for better > > use :) > > > > Rename PG_dropbehind to PG_reclaim and r