Re: [PATCH 2/9] Drop cpumask auto select patch
On Thu, Oct 24, 2019 at 09:41:22AM -0500, Jeremy Linton wrote: > Hi, > > On 8/22/19 11:36 AM, Laura Abbott wrote: > > On 8/22/19 8:58 AM, Prarit Bhargava wrote: > > > On 8/19/19 9:15 AM, Laura Abbott wrote: > > > > On 8/16/19 2:57 PM, Paul Bolle wrote: > > > > > Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: > > > > > > RHEL has a larger NR_CPU value, though. For example, it's 8192 on > > > > > > x86-64, while Fedora 31 has 1024. > > > > > > > > > > On the Fedora x86-64 debug builds it's 8192 again. Why's that? > > > > > > > > > > > > > > > Paul Bolle > > > > > > > > > > > > > That's the option for max cpus. We don't want to turn it on in all > > > > Fedora builds since it would use up more resources we probably don't > > > > actually need. Turning on for debugging in Fedora is okay though. > > > > RHEL is focused on larger footprints and makes the trade off to > > > > have it enabled all the time. > > > > > > > > > > I think I measured the impact of 8192 vs 512 (or 256?) a long time > > > ago and we > > > are talking about _k_ of memory. We should stick with what upstream > > > has at > > > 8192. It's easier to debug when we have the same value as the > > > default IMO. > > > > > > Having said that, it has been a long time since I had to debug a > > > NR_CPUS/nr_cpus > > > issue in the kernel. We're just not seeing bugs around the value > > > anymore. > > > > > > > I was going to ask about the actual impact of a larger number of CPUs. > > If it's > > actually only k of memory it's probably better to just set MAXCPUS all > > the time. > > Even the lowest end machines probably see more change when frameworks > > change. > > > > And yes, I also think that we've come a long way so NR_CPUS is less of > > an important > > option to optimize these days. I think I'll just submit another patch to > > just do > > the max cpus. > > > > Forgive me if you have already posted (didn't see it yet). > > Its probably a good idea to bump the aarch64 config at the same time. Some > aarch64 "desktop" machines is already at the 256 core limit currently in > use. > I've bumped aarch64 up to 4096, s390x up to 512, and powerpc up to 2048 in Rawhide and it'll be in the build after v5.4-rc6. - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
Hi, On 8/22/19 11:36 AM, Laura Abbott wrote: On 8/22/19 8:58 AM, Prarit Bhargava wrote: On 8/19/19 9:15 AM, Laura Abbott wrote: On 8/16/19 2:57 PM, Paul Bolle wrote: Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle That's the option for max cpus. We don't want to turn it on in all Fedora builds since it would use up more resources we probably don't actually need. Turning on for debugging in Fedora is okay though. RHEL is focused on larger footprints and makes the trade off to have it enabled all the time. I think I measured the impact of 8192 vs 512 (or 256?) a long time ago and we are talking about _k_ of memory. We should stick with what upstream has at 8192. It's easier to debug when we have the same value as the default IMO. Having said that, it has been a long time since I had to debug a NR_CPUS/nr_cpus issue in the kernel. We're just not seeing bugs around the value anymore. I was going to ask about the actual impact of a larger number of CPUs. If it's actually only k of memory it's probably better to just set MAXCPUS all the time. Even the lowest end machines probably see more change when frameworks change. And yes, I also think that we've come a long way so NR_CPUS is less of an important option to optimize these days. I think I'll just submit another patch to just do the max cpus. Forgive me if you have already posted (didn't see it yet). Its probably a good idea to bump the aarch64 config at the same time. Some aarch64 "desktop" machines is already at the 256 core limit currently in use. Thanks, Laura P. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/22/19 8:58 AM, Prarit Bhargava wrote: On 8/19/19 9:15 AM, Laura Abbott wrote: On 8/16/19 2:57 PM, Paul Bolle wrote: Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle That's the option for max cpus. We don't want to turn it on in all Fedora builds since it would use up more resources we probably don't actually need. Turning on for debugging in Fedora is okay though. RHEL is focused on larger footprints and makes the trade off to have it enabled all the time. I think I measured the impact of 8192 vs 512 (or 256?) a long time ago and we are talking about _k_ of memory. We should stick with what upstream has at 8192. It's easier to debug when we have the same value as the default IMO. Having said that, it has been a long time since I had to debug a NR_CPUS/nr_cpus issue in the kernel. We're just not seeing bugs around the value anymore. I was going to ask about the actual impact of a larger number of CPUs. If it's actually only k of memory it's probably better to just set MAXCPUS all the time. Even the lowest end machines probably see more change when frameworks change. And yes, I also think that we've come a long way so NR_CPUS is less of an important option to optimize these days. I think I'll just submit another patch to just do the max cpus. Thanks, Laura P. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/19/19 9:15 AM, Laura Abbott wrote: > On 8/16/19 2:57 PM, Paul Bolle wrote: >> Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: >>> RHEL has a larger NR_CPU value, though. For example, it's 8192 on >>> x86-64, while Fedora 31 has 1024. >> >> On the Fedora x86-64 debug builds it's 8192 again. Why's that? >> >> >> Paul Bolle >> > > That's the option for max cpus. We don't want to turn it on in all > Fedora builds since it would use up more resources we probably don't > actually need. Turning on for debugging in Fedora is okay though. > RHEL is focused on larger footprints and makes the trade off to > have it enabled all the time. > I think I measured the impact of 8192 vs 512 (or 256?) a long time ago and we are talking about _k_ of memory. We should stick with what upstream has at 8192. It's easier to debug when we have the same value as the default IMO. Having said that, it has been a long time since I had to debug a NR_CPUS/nr_cpus issue in the kernel. We're just not seeing bugs around the value anymore. P. > Thanks, > Laura > ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 2:55 PM, Paul Bolle wrote: Hi Laura, Laura Abbott schreef op do 15-08-2019 om 15:57 [-0400]: .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- kernel.spec | 2 -- ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 --- 3 files changed, 1 insertion(+), 37 deletions(-) delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS index 27d187f4d..9ce2b2de6 100644 --- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS +++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS @@ -1 +1 @@ -CONFIG_NR_CPUS=1024 +CONFIG_NR_CPUS=512 This patch needs an included regeneration of the kernel-*.config files to be complete. Thanks, Paul Bolle Thanks for the reminder ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 2:57 PM, Paul Bolle wrote: Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle That's the option for max cpus. We don't want to turn it on in all Fedora builds since it would use up more resources we probably don't actually need. Turning on for debugging in Fedora is okay though. RHEL is focused on larger footprints and makes the trade off to have it enabled all the time. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: > RHEL has a larger NR_CPU value, though. For example, it's 8192 on > x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
Hi Laura, Laura Abbott schreef op do 15-08-2019 om 15:57 [-0400]: > .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- > kernel.spec | 2 -- > ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 --- > 3 files changed, 1 insertion(+), 37 deletions(-) > delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch > > diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS > b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS > index 27d187f4d..9ce2b2de6 100644 > --- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS > +++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS > @@ -1 +1 @@ > -CONFIG_NR_CPUS=1024 > +CONFIG_NR_CPUS=512 This patch needs an included regeneration of the kernel-*.config files to be complete. Thanks, Paul Bolle ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
* Laura Abbott: > On 8/16/19 6:58 AM, Josh Boyer wrote: >> On Thu, Aug 15, 2019 at 3:57 PM Laura Abbott wrote: >>> >>> We've been carrying a patch to make CPUMASK_OFFSTACK selectable >>> without debugging for a long time now. The comment said this was >>> going to be replaced with something else but that never seemed >>> to happen. We're carrying it to have a higher number of CPUs but >>> at this point I don't think it's worth it since the upper bound is >>> now 512. This should be enough for most Fedora use cases so just >>> drop the patch. >> >> I likely agree, but copying Prarit because this was something he and I >> poked at forever ago. >> > > Given that RHEL no longer bothers with this I hope he would be > okay with it :) RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. Thanks, Florian ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 6:58 AM, Josh Boyer wrote:
On Thu, Aug 15, 2019 at 3:57 PM Laura Abbott wrote:
We've been carrying a patch to make CPUMASK_OFFSTACK selectable
without debugging for a long time now. The comment said this was
going to be replaced with something else but that never seemed
to happen. We're carrying it to have a higher number of CPUs but
at this point I don't think it's worth it since the upper bound is
now 512. This should be enough for most Fedora use cases so just
drop the patch.
I likely agree, but copying Prarit because this was something he and I
poked at forever ago.
Given that RHEL no longer bothers with this I hope he would be
okay with it :)
josh
Signed-off-by: Laura Abbott
---
.../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +-
kernel.spec | 2 --
...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 ---
3 files changed, 1 insertion(+), 37 deletions(-)
delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
index 27d187f4d..9ce2b2de6 100644
--- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
+++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
@@ -1 +1 @@
-CONFIG_NR_CPUS=1024
+CONFIG_NR_CPUS=512
diff --git a/kernel.spec b/kernel.spec
index a662ee004..4253ff035 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
# Standalone patches
# 100 - Generic long running patches
-Patch110: lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
-
Patch111: input-kill-stupid-messages.patch
Patch112: die-floppy-die.patch
diff --git a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
b/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
deleted file mode 100644
index 5e6d6611e..0
--- a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From: Josh Boyer
-Date: Mon, 11 Nov 2013 08:39:16 -0500
-Subject: [PATCH] lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
- dependency
-
-When CPUMASK_OFFSTACK was added in 2008, it was dependent upon
-DEBUG_PER_CPU_MAPS being enabled, or an architecture could select it.
-The debug dependency adds additional overhead that isn't required for
-operation of the feature, and we need CPUMASK_OFFSTACK to increase the
-NR_CPUS value beyond 512 on x86. We drop the current dependency and make
-sure SMP is set.
-
-Bugzilla: N/A
-Upstream-status: Nak'd, supposedly replacement coming to auto-select
-
-Signed-off-by: Josh Boyer
- lib/Kconfig | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/lib/Kconfig b/lib/Kconfig
-index 3a2ef67db6c7..4af1e7e5a611 100644
a/lib/Kconfig
-+++ b/lib/Kconfig
-@@ -396,7 +396,8 @@ config CHECK_SIGNATURE
- bool
-
- config CPUMASK_OFFSTACK
-- bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
-+ bool "Force CPU masks off stack"
-+ depends on SMP
- help
- Use dynamic allocation for cpumask_var_t, instead of putting
- them on the stack. This is a bit more expensive, but avoids
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On Thu, Aug 15, 2019 at 3:57 PM Laura Abbott wrote:
>
> We've been carrying a patch to make CPUMASK_OFFSTACK selectable
> without debugging for a long time now. The comment said this was
> going to be replaced with something else but that never seemed
> to happen. We're carrying it to have a higher number of CPUs but
> at this point I don't think it's worth it since the upper bound is
> now 512. This should be enough for most Fedora use cases so just
> drop the patch.
I likely agree, but copying Prarit because this was something he and I
poked at forever ago.
josh
> Signed-off-by: Laura Abbott
> ---
> .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +-
> kernel.spec | 2 --
> ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 ---
> 3 files changed, 1 insertion(+), 37 deletions(-)
> delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
>
> diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
> b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
> index 27d187f4d..9ce2b2de6 100644
> --- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
> +++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
> @@ -1 +1 @@
> -CONFIG_NR_CPUS=1024
> +CONFIG_NR_CPUS=512
> diff --git a/kernel.spec b/kernel.spec
> index a662ee004..4253ff035 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
> # Standalone patches
> # 100 - Generic long running patches
>
> -Patch110: lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
> -
> Patch111: input-kill-stupid-messages.patch
>
> Patch112: die-floppy-die.patch
> diff --git a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
> b/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
> deleted file mode 100644
> index 5e6d6611e..0
> --- a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -From: Josh Boyer
> -Date: Mon, 11 Nov 2013 08:39:16 -0500
> -Subject: [PATCH] lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
> - dependency
> -
> -When CPUMASK_OFFSTACK was added in 2008, it was dependent upon
> -DEBUG_PER_CPU_MAPS being enabled, or an architecture could select it.
> -The debug dependency adds additional overhead that isn't required for
> -operation of the feature, and we need CPUMASK_OFFSTACK to increase the
> -NR_CPUS value beyond 512 on x86. We drop the current dependency and make
> -sure SMP is set.
> -
> -Bugzilla: N/A
> -Upstream-status: Nak'd, supposedly replacement coming to auto-select
> -
> -Signed-off-by: Josh Boyer
>
> - lib/Kconfig | 3 ++-
> - 1 file changed, 2 insertions(+), 1 deletion(-)
> -
> -diff --git a/lib/Kconfig b/lib/Kconfig
> -index 3a2ef67db6c7..4af1e7e5a611 100644
> a/lib/Kconfig
> -+++ b/lib/Kconfig
> -@@ -396,7 +396,8 @@ config CHECK_SIGNATURE
> - bool
> -
> - config CPUMASK_OFFSTACK
> -- bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
> -+ bool "Force CPU masks off stack"
> -+ depends on SMP
> - help
> - Use dynamic allocation for cpumask_var_t, instead of putting
> - them on the stack. This is a bit more expensive, but avoids
> --
> 2.21.0
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 2/9] Drop cpumask auto select patch
We've been carrying a patch to make CPUMASK_OFFSTACK selectable
without debugging for a long time now. The comment said this was
going to be replaced with something else but that never seemed
to happen. We're carrying it to have a higher number of CPUs but
at this point I don't think it's worth it since the upper bound is
now 512. This should be enough for most Fedora use cases so just
drop the patch.
Signed-off-by: Laura Abbott
---
.../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +-
kernel.spec | 2 --
...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 ---
3 files changed, 1 insertion(+), 37 deletions(-)
delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
index 27d187f4d..9ce2b2de6 100644
--- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
+++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
@@ -1 +1 @@
-CONFIG_NR_CPUS=1024
+CONFIG_NR_CPUS=512
diff --git a/kernel.spec b/kernel.spec
index a662ee004..4253ff035 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
# Standalone patches
# 100 - Generic long running patches
-Patch110: lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
-
Patch111: input-kill-stupid-messages.patch
Patch112: die-floppy-die.patch
diff --git a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
b/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
deleted file mode 100644
index 5e6d6611e..0
--- a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From: Josh Boyer
-Date: Mon, 11 Nov 2013 08:39:16 -0500
-Subject: [PATCH] lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
- dependency
-
-When CPUMASK_OFFSTACK was added in 2008, it was dependent upon
-DEBUG_PER_CPU_MAPS being enabled, or an architecture could select it.
-The debug dependency adds additional overhead that isn't required for
-operation of the feature, and we need CPUMASK_OFFSTACK to increase the
-NR_CPUS value beyond 512 on x86. We drop the current dependency and make
-sure SMP is set.
-
-Bugzilla: N/A
-Upstream-status: Nak'd, supposedly replacement coming to auto-select
-
-Signed-off-by: Josh Boyer
- lib/Kconfig | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/lib/Kconfig b/lib/Kconfig
-index 3a2ef67db6c7..4af1e7e5a611 100644
a/lib/Kconfig
-+++ b/lib/Kconfig
-@@ -396,7 +396,8 @@ config CHECK_SIGNATURE
- bool
-
- config CPUMASK_OFFSTACK
-- bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
-+ bool "Force CPU masks off stack"
-+ depends on SMP
- help
- Use dynamic allocation for cpumask_var_t, instead of putting
- them on the stack. This is a bit more expensive, but avoids
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
