On Sun, 23 Jun 2024 07:11:24 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: f76698bd9a8ca01d3581236082d786e9a6b72bb7 Add linux-next
> specific files for 20240621
>
> Error/Warning reports:
>
> https://
On Wed, 27 Mar 2024 13:00:43 -0700 Samuel Holland
wrote:
> Now that all previously-supported architectures select
> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
> of the existing list of architectures. It can also take advantage of the
> common kernel-mode FPU API and
On Sun, 26 Feb 2023 01:10:55 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 8232539f864ca60474e38eb42d451f5c26415856 Add linux-next
> specific files for 20230225
>
> Error/Warning reports:
>
> mm/page_
On Wed, 25 Jan 2023 00:37:05 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: a54df7622717a40ddec95fd98086aff8ba7839a6 Add linux-next
> specific files for 20230124
>
> Error/Warning: (recently discovered
On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this s
On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this s
On Wed, 28 Sep 2022 22:01:22 +1000 Alistair Popple wrote:
> @@ -1401,22 +1494,7 @@ static int dmirror_device_init(struct dmirror_device
> *mdevice, int id)
>
> static void dmirror_device_remove(struct dmirror_device *mdevice)
> {
> - unsigned int i;
> -
> - if (mdevice->devmem_chunks
On Mon, 25 Jul 2022 21:22:06 -0500 "Sierra Guiza, Alejandro (Alex)"
wrote:
> >> a) add the || to the end of the previous line
> >> b) indent such the we have a nice-to-read alignment
> >>
> >> if (!list_empty(&movable_page_list) || isolation_error_count ||
> >> coherent_pages)
> >>
> > I mi
On Mon, 18 Jul 2022 12:56:29 +0200 David Hildenbrand wrote:
> > /*
> > * Try to move out any movable page before pinning the range.
> > */
> > @@ -1919,7 +1948,8 @@ static long check_and_migrate_movable_pages(unsigned
> > long nr_pages,
> >
On Thu, 30 Jun 2022 00:15:06 +0200 David Hildenbrand wrote:
> On 30.06.22 00:08, Felix Kuehling wrote:
> > On 2022-06-29 03:33, David Hildenbrand wrote:
> >> On 29.06.22 05:54, Alex Sierra wrote:
> >>> is_pinnable_page() and folio_is_pinnable() were renamed to
> >>> is_longterm_pinnable_page() an
On Wed, 29 Jun 2022 11:59:26 +0200 David Hildenbrand wrote:
> On 29.06.22 05:54, Alex Sierra wrote:
> > With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> > device-managed anonymous pages that are not LRU pages. Although they
> > behave like normal pages for purposes of mapping in C
On Wed, 29 Jun 2022 18:08:40 -0400 Felix Kuehling
wrote:
> >
> > I'd have called it "is_longterm_pinnable_page", but I am not a native
> > speaker, so no strong opinion :)
>
> I think only the patch title has the name backwards. The code uses
> is_longterm_pinnable_page.
Patch title was quite
On Tue, 31 May 2022 15:00:28 -0500 Alex Sierra wrote:
> This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
> for current 5.18.0
I plan to move this series into the non-rebasing mm-stable branch in a
few days. Unless sternly told not to do so!
On Tue, 31 May 2022 10:56:23 -0500 Alex Sierra wrote:
> new ioctl cmd added to query zone device type. This will be
> used once the test_hmm adds zone device coherent type.
>
> @@ -1026,6 +1027,15 @@ static int dmirror_snapshot(struct dmirror *dmirror,
> return ret;
> }
>
> +static int
On Wed, 25 May 2022 23:07:35 +0100 Jessica Clarke wrote:
> This is i386, so an unsigned long is 32-bit, but i_blocks is a blkcnt_t
> i.e. a u64, which makes the shift without a cast of the LHS fishy.
Ah, of course, thanks. I remember 32 bits ;)
--- a/mm/shmem.c~mm-shmemc-suppress-shift-warning
On Thu, 26 May 2022 05:35:20 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 8cb8311e95e3bb58bd84d6350365f14a718faa6d Add linux-next
> specific files for 20220525
>
> Error/Warning reports:
>
> ...
>
>
On Wed, 18 May 2022 20:41:27 -0700 Guenter Roeck wrote:
> On 5/18/22 17:55, kernel test robot wrote:
> > tree/branch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next
> > specific files for 2
On Thu, 27 Jan 2022 17:20:40 -0600 "Sierra Guiza, Alejandro (Alex)"
wrote:
> Andrew,
> We're somehow new on this procedure. Are you referring to rebase this
> patch series to
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> <5.17-rc1 tag>?
No, against current Linus mainli
On Wed, 26 Jan 2022 21:09:39 -0600 Alex Sierra wrote:
> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> owned by a device that can be mapped into CPU page tables like
> MEMORY_DEVICE_GENERIC and can also be migrated like
> MEMORY_DEVICE_PRIVATE.
Some more reviewer input a
On Tue, 12 Oct 2021 15:56:29 -0300 Jason Gunthorpe wrote:
> > To what other uses will this infrastructure be put?
> >
> > Because I must ask: if this feature is for one single computer which
> > presumably has a custom kernel, why add it to mainline Linux?
>
> Well, it certainly isn't just "one
On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> owned by a device that can be mapped into CPU page tables like
> MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE.
> With MEMORY_DEVICE_COHERENT
On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> There is no reason for a user to select this or not directly - it should
> be selected by drivers that are going to use the feature, similar to how
> CONFIG_HMM_MIRROR works.
>
> Currently all drivers provide
On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook wrote:
> > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> >
> > Andrew, could you take a look and give your Acked-by or pick them up
> > directly?
>
> Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> via Andrew? I
On Fri, 10 May 2019 19:53:23 + "Kuehling, Felix"
wrote:
> From: Philip Yang
>
> While the page is migrating by NUMA balancing, HMM failed to detect this
> condition and still return the old page. Application will use the new
> page migrated, but driver pass the old page physical address to
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to som
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
> > Any suggestions regarding how the driver developers can test this code
> > path? I don't think we presently have a way to fake an oom-killing
> > event? Perhaps we should add such a thing, given the problems we're
> > having with that f
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 20 Feb 2018 10:03:56 +0200 Jani Nikula
wrote:
> On Mon, 19 Feb 2018, Pavel Machek wrote:
> > On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> >> Yeah, pls split this into one patch per area, with a suitable patch
> >> subject prefix. Look at git log of each file to get a feeling for w
On Thu, 18 Jan 2018 11:47:48 -0500 Andrey Grodzovsky
wrote:
> Hi, this series is a revised version of an RFC sent by Christian König
> a few years ago. The original RFC can be found at
> https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
>
> This is the same idea and I
On Mon, 28 Aug 2017 21:53:10 -0400 Felix Kuehling
wrote:
> This adds a statically sized closed hash table implementation with
> low memory and CPU overhead. The API is inspired by kfifo.
>
> Storing, retrieving and deleting data does not involve any dynamic
> memory management, which makes it i
31 matches
Mail list logo
