All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: ocfs2-devel@oss.oracle.com, linux-fbdev@vger.kernel.org,
	dri-devel@lists.freedesktop.org, netdev@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, linux-media@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-rdma@vger.kernel.org,
	dmaengine@vger.kernel.org, linux-block@vger.kernel.org,
	sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-ia64@vger.kernel.org, linux-alpha@vger.kernel.org
Subject: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
Date: Mon, 12 Nov 2018 17:17:19 +0530	[thread overview]
Message-ID: <d947edec-8c5a-78d7-4069-687ac4ad7cb8@arm.com> (raw)

On 11/12/2018 02:13 PM, Hans Verkuil wrote:
> On 11/12/2018 03:41 AM, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc64le etc with their default config which might not have
>> compiled tested all driver related changes. I will appreciate folks giving
>> this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
> The 'node' in the drivers/media and the drivers/video sources has nothing to
> do with numa. It's an index for a framebuffer instead (i.e. the X in /dev/fbX).

Thanks for the input. Will drop the changes there.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: ocfs2-devel@oss.oracle.com, linux-fbdev@vger.kernel.org,
	dri-devel@lists.freedesktop.org, netdev@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, linux-media@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-rdma@vger.kernel.org,
	dmaengine@vger.kernel.org, linux-block@vger.kernel.org,
	sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-ia64@vger.kernel.org, linux-alpha@vger.kernel.org
Subject: Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
Date: Mon, 12 Nov 2018 17:17:19 +0530	[thread overview]
Message-ID: <d947edec-8c5a-78d7-4069-687ac4ad7cb8@arm.com> (raw)
In-Reply-To: <de754de5-cdf9-87d2-7ab2-a3630c034121@xs4all.nl>



On 11/12/2018 02:13 PM, Hans Verkuil wrote:
> On 11/12/2018 03:41 AM, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc64le etc with their default config which might not have
>> compiled tested all driver related changes. I will appreciate folks giving
>> this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
> The 'node' in the drivers/media and the drivers/video sources has nothing to
> do with numa. It's an index for a framebuffer instead (i.e. the X in /dev/fbX).

Thanks for the input. Will drop the changes there.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: ocfs2-devel@oss.oracle.com, linux-fbdev@vger.kernel.org,
	dri-devel@lists.freedesktop.org, netdev@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, linux-media@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-rdma@vger.kernel.org,
	dmaengine@vger.kernel.org, linux-block@vger.kernel.org,
	sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-ia64@vger.kernel.org, linux-alpha@vger.kernel.org
Subject: Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
Date: Mon, 12 Nov 2018 11:59:19 +0000	[thread overview]
Message-ID: <d947edec-8c5a-78d7-4069-687ac4ad7cb8@arm.com> (raw)
In-Reply-To: <1541990515-11670-1-git-send-email-anshuman.khandual@arm.com>



On 11/12/2018 02:13 PM, Hans Verkuil wrote:
> On 11/12/2018 03:41 AM, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc64le etc with their default config which might not have
>> compiled tested all driver related changes. I will appreciate folks giving
>> this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
> The 'node' in the drivers/media and the drivers/video sources has nothing to
> do with numa. It's an index for a framebuffer instead (i.e. the X in /dev/fbX).

Thanks for the input. Will drop the changes there.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-block@vger.kernel.org,
	sparclinux@vger.kernel.org, iommu@lists.linux-foundation.org,
	intel-wired-lan@lists.osuosl.org, linux-alpha@vger.kernel.org,
	dmaengine@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	ocfs2-devel@oss.oracle.com, linux-media@vger.kernel.org
Subject: Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE
Date: Mon, 12 Nov 2018 17:17:19 +0530	[thread overview]
Message-ID: <d947edec-8c5a-78d7-4069-687ac4ad7cb8@arm.com> (raw)
In-Reply-To: <de754de5-cdf9-87d2-7ab2-a3630c034121@xs4all.nl>



On 11/12/2018 02:13 PM, Hans Verkuil wrote:
> On 11/12/2018 03:41 AM, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc64le etc with their default config which might not have
>> compiled tested all driver related changes. I will appreciate folks giving
>> this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
> The 'node' in the drivers/media and the drivers/video sources has nothing to
> do with numa. It's an index for a framebuffer instead (i.e. the X in /dev/fbX).

Thanks for the input. Will drop the changes there.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC] mm: Replace all open encodings for NUMA_NO_NODE
Date: Mon, 12 Nov 2018 17:17:19 +0530	[thread overview]
Message-ID: <d947edec-8c5a-78d7-4069-687ac4ad7cb8@arm.com> (raw)
In-Reply-To: <de754de5-cdf9-87d2-7ab2-a3630c034121@xs4all.nl>



On 11/12/2018 02:13 PM, Hans Verkuil wrote:
> On 11/12/2018 03:41 AM, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc64le etc with their default config which might not have
>> compiled tested all driver related changes. I will appreciate folks giving
>> this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
> The 'node' in the drivers/media and the drivers/video sources has nothing to
> do with numa. It's an index for a framebuffer instead (i.e. the X in /dev/fbX).

Thanks for the input. Will drop the changes there.

             reply	other threads:[~2018-11-12 11:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 11:47 Anshuman Khandual [this message]
2018-11-12 11:59 ` [RFC] mm: Replace all open encodings for NUMA_NO_NODE Anshuman Khandual
2018-11-12 11:47 ` [Intel-wired-lan] " Anshuman Khandual
2018-11-12 11:47 ` Anshuman Khandual
2018-11-12 11:47 ` Anshuman Khandual
  -- strict thread matches above, loose matches on Subject: below --
2018-11-12  8:43 Hans Verkuil
2018-11-12  8:43 ` [Intel-wired-lan] " Hans Verkuil
2018-11-12  8:43 ` Hans Verkuil
2018-11-12  8:43 ` Hans Verkuil
2018-11-12  8:43 ` Hans Verkuil
2018-11-12  8:43 ` Hans Verkuil
2018-11-12  4:14 Anshuman Khandual
2018-11-12  4:26 ` Anshuman Khandual
2018-11-12  4:14 ` Anshuman Khandual
2018-11-12  4:14 ` Anshuman Khandual
2018-11-12  4:10 Anshuman Khandual
2018-11-12  4:22 ` Anshuman Khandual
2018-11-12  4:10 ` [Intel-wired-lan] " Anshuman Khandual
2018-11-12  4:10 ` Anshuman Khandual
2018-11-12  4:10 ` Anshuman Khandual
2018-11-12  3:57 Joseph Qi
2018-11-12  3:57 ` [Intel-wired-lan] " Joseph Qi
2018-11-12  3:57 ` Joseph Qi
2018-11-12  3:57 ` [Ocfs2-devel] " Joseph Qi
2018-11-12  3:57 ` Joseph Qi
2018-11-12  3:57 ` Joseph Qi
2018-11-12  2:41 Anshuman Khandual
2018-11-12  2:53 ` Anshuman Khandual
2018-11-12  2:41 ` [Intel-wired-lan] " Anshuman Khandual
2018-11-12  2:41 ` Anshuman Khandual
2018-11-12  2:41 ` Anshuman Khandual

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=d947edec-8c5a-78d7-4069-687ac4ad7cb8@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=sparclinux@vger.kernel.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: link
Be 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.