linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [akpm-mm:mm-unstable 9/30] mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid'
@ 2024-07-23 16:32 kernel test robot
  2024-07-23 16:35 ` Zi Yan
  0 siblings, 1 reply; 4+ messages in thread
From: kernel test robot @ 2024-07-23 16:32 UTC (permalink / raw)
  To: Zi Yan
  Cc: oe-kbuild-all, Andrew Morton, Linux Memory Management List, Huang, Ying

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
head:   cecb3db438d76f7c1005fd52689809696a330474
commit: c57ceb62609b36d1a01e8bdd894d032379999b75 [9/30] memory tiering: introduce folio_has_cpupid() check
config: sparc-allmodconfig (https://download.01.org/0day-ci/archive/20240724/202407240024.Lhu1XDok-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240724/202407240024.Lhu1XDok-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202407240024.Lhu1XDok-lkp@intel.com/

All errors (new ones prefixed by >>):

>> mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid'
      64 | bool folio_has_cpupid(struct folio *folio)
         |      ^~~~~~~~~~~~~~~~
   In file included from mm/internal.h:11,
                    from mm/memory-tiers.c:11:
   include/linux/mm.h:1796:20: note: previous definition of 'folio_has_cpupid' with type 'bool(struct folio *)' {aka '_Bool(struct folio *)'}
    1796 | static inline bool folio_has_cpupid(struct folio *folio)
         |                    ^~~~~~~~~~~~~~~~


vim +/folio_has_cpupid +64 mm/memory-tiers.c

    53	
    54	/**
    55	 * folio_has_cpupid - check if a folio has cpupid information
    56	 * @folio: folio to check
    57	 *
    58	 * folio's _last_cpupid field is repurposed by memory tiering. In memory
    59	 * tiering mode, cpupid of slow memory folio (not toptier memory) is used to
    60	 * record page access time.
    61	 *
    62	 * Return: the folio _last_cpupid is used as cpupid
    63	 */
  > 64	bool folio_has_cpupid(struct folio *folio)
    65	{
    66		return !(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) ||
    67		       node_is_toptier(folio_nid(folio));
    68	}
    69	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [akpm-mm:mm-unstable 9/30] mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid'
  2024-07-23 16:32 [akpm-mm:mm-unstable 9/30] mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid' kernel test robot
@ 2024-07-23 16:35 ` Zi Yan
  2024-07-23 21:45   ` Andrew Morton
  0 siblings, 1 reply; 4+ messages in thread
From: Zi Yan @ 2024-07-23 16:35 UTC (permalink / raw)
  To: kernel test robot
  Cc: oe-kbuild-all, Andrew Morton, Linux Memory Management List, Huang, Ying

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

On 23 Jul 2024, at 12:32, kernel test robot wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
> head:   cecb3db438d76f7c1005fd52689809696a330474
> commit: c57ceb62609b36d1a01e8bdd894d032379999b75 [9/30] memory tiering: introduce folio_has_cpupid() check
> config: sparc-allmodconfig (https://download.01.org/0day-ci/archive/20240724/202407240024.Lhu1XDok-lkp@intel.com/config)
> compiler: sparc64-linux-gcc (GCC) 14.1.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240724/202407240024.Lhu1XDok-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202407240024.Lhu1XDok-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>>> mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid'
>       64 | bool folio_has_cpupid(struct folio *folio)
>          |      ^~~~~~~~~~~~~~~~
>    In file included from mm/internal.h:11,
>                     from mm/memory-tiers.c:11:
>    include/linux/mm.h:1796:20: note: previous definition of 'folio_has_cpupid' with type 'bool(struct folio *)' {aka '_Bool(struct folio *)'}
>     1796 | static inline bool folio_has_cpupid(struct folio *folio)
>          |                    ^~~~~~~~~~~~~~~~
>
>
> vim +/folio_has_cpupid +64 mm/memory-tiers.c
>
>     53	
>     54	/**
>     55	 * folio_has_cpupid - check if a folio has cpupid information
>     56	 * @folio: folio to check
>     57	 *
>     58	 * folio's _last_cpupid field is repurposed by memory tiering. In memory
>     59	 * tiering mode, cpupid of slow memory folio (not toptier memory) is used to
>     60	 * record page access time.
>     61	 *
>     62	 * Return: the folio _last_cpupid is used as cpupid
>     63	 */
>   > 64	bool folio_has_cpupid(struct folio *folio)
>     65	{
>     66		return !(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) ||
>     67		       node_is_toptier(folio_nid(folio));
>     68	}
>     69	

The error has been reported by Lorenzo Stoakes at: https://lore.kernel.org/linux-mm/6effd690-3cf2-46bc-8061-2d19922ad4fa@lucifer.local/.
I will fix it in the next version.

Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [akpm-mm:mm-unstable 9/30] mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid'
  2024-07-23 16:35 ` Zi Yan
@ 2024-07-23 21:45   ` Andrew Morton
  2024-07-23 21:51     ` Zi Yan
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2024-07-23 21:45 UTC (permalink / raw)
  To: Zi Yan
  Cc: kernel test robot, oe-kbuild-all, Linux Memory Management List,
	Huang, Ying

On Tue, 23 Jul 2024 12:35:23 -0400 Zi Yan <ziy@nvidia.com> wrote:

> >   > 64	bool folio_has_cpupid(struct folio *folio)
> >     65	{
> >     66		return !(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) ||
> >     67		       node_is_toptier(folio_nid(folio));
> >     68	}
> >     69	
> 
> The error has been reported by Lorenzo Stoakes at: https://lore.kernel.org/linux-mm/6effd690-3cf2-46bc-8061-2d19922ad4fa@lucifer.local/.
> I will fix it in the next version.

a) "in the next version" is too casual, sorry.  We broke the build!  Panic!
   I'll apply this:

--- a/mm/memory-tiers.c~memory-tiering-introduce-folio_has_cpupid-check-fix
+++ a/mm/memory-tiers.c
@@ -51,6 +51,7 @@ static const struct bus_type memory_tier
 	.dev_name = "memory_tier",
 };
 
+#ifdef CONFIG_NUMA_BALANCING
 /**
  * folio_has_cpupid - check if a folio has cpupid information
  * @folio: folio to check
@@ -66,6 +67,7 @@ bool folio_has_cpupid(struct folio *foli
 	return !(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) ||
 	       node_is_toptier(folio_nid(folio));
 }
+#endif
 
 #ifdef CONFIG_MIGRATION
 static int top_tier_adistance;
_

b) is a next version planned so soon?  If so, why was this version
   sent?  Please try to avoid sending an entire new patchset for a few
   trivial fixups.  Just send the fixups!


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [akpm-mm:mm-unstable 9/30] mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid'
  2024-07-23 21:45   ` Andrew Morton
@ 2024-07-23 21:51     ` Zi Yan
  0 siblings, 0 replies; 4+ messages in thread
From: Zi Yan @ 2024-07-23 21:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: kernel test robot, oe-kbuild-all, Linux Memory Management List,
	Huang, Ying

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

On 23 Jul 2024, at 17:45, Andrew Morton wrote:

> On Tue, 23 Jul 2024 12:35:23 -0400 Zi Yan <ziy@nvidia.com> wrote:
>
>>>   > 64	bool folio_has_cpupid(struct folio *folio)
>>>     65	{
>>>     66		return !(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) ||
>>>     67		       node_is_toptier(folio_nid(folio));
>>>     68	}
>>>     69	
>>
>> The error has been reported by Lorenzo Stoakes at: https://lore.kernel.org/linux-mm/6effd690-3cf2-46bc-8061-2d19922ad4fa@lucifer.local/.
>> I will fix it in the next version.
>
> a) "in the next version" is too casual, sorry.  We broke the build!  Panic!
>    I'll apply this:
>
> --- a/mm/memory-tiers.c~memory-tiering-introduce-folio_has_cpupid-check-fix
> +++ a/mm/memory-tiers.c
> @@ -51,6 +51,7 @@ static const struct bus_type memory_tier
>  	.dev_name = "memory_tier",
>  };
>
> +#ifdef CONFIG_NUMA_BALANCING
>  /**
>   * folio_has_cpupid - check if a folio has cpupid information
>   * @folio: folio to check
> @@ -66,6 +67,7 @@ bool folio_has_cpupid(struct folio *foli
>  	return !(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) ||
>  	       node_is_toptier(folio_nid(folio));
>  }
> +#endif
>
>  #ifdef CONFIG_MIGRATION
>  static int top_tier_adistance;
> _

Thanks. It does fix the build issue.

>
> b) is a next version planned so soon?  If so, why was this version
>    sent?  Please try to avoid sending an entire new patchset for a few
>    trivial fixups.  Just send the fixups!

There is a discussion on renaming folio_has_cpupid in patch 2[1]. I am
waiting for the feedback before sending out a new version. The new
version renames the function and reverse the logic. I assume it does not
count as fixups. Let me know if you think otherwise.


[1] https://lore.kernel.org/linux-mm/D2WXTV2186EV.2OTDTPCJSNVN1@nvidia.com/

Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-07-23 21:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-07-23 16:32 [akpm-mm:mm-unstable 9/30] mm/memory-tiers.c:64:6: error: redefinition of 'folio_has_cpupid' kernel test robot
2024-07-23 16:35 ` Zi Yan
2024-07-23 21:45   ` Andrew Morton
2024-07-23 21:51     ` Zi Yan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox