* [LTP] [PATCH] tst_ncpus_max: use kernel_max if available @ 2014-08-26 10:01 Jan Stancek 2014-08-26 10:06 ` chrubis 0 siblings, 1 reply; 7+ messages in thread From: Jan Stancek @ 2014-08-26 10:01 UTC (permalink / raw) To: ltp-list sched_getaffinity() and sched_setaffinity() cares about number of possible CPUs the OS or hardware can support, which can be larger than what sysconf(_SC_NPROCESSORS_CONF) currently provides (by enumarating /sys/devices/system/cpu/cpu* entries). Use /sys/devices/system/cpu/kernel_max, if available. This represents NR_CPUS-1, a compile time option which specifies "maximum number of CPUs which this kernel will support". This should give us cpu mask size large enough for any purposes. If the kernel_max sysfs file is not available, fall back to _SC_NPROCESSORS_CONF. Signed-off-by: Jan Stancek <jstancek@redhat.com> --- lib/tst_cpu.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-) Tested on system supporting CPU hotplug: NR_CPUS:4096 nr_cpumask_bits:144 nr_cpu_ids:144 nr_node_ids:1 # cat /sys/devices/system/cpu/online 0-15 # cat /sys/devices/system/cpu/offline 16-143 # cat /sys/devices/system/cpu/possible 0-143 # cat /sys/devices/system/cpu/kernel_max 4095 diff --git a/lib/tst_cpu.c b/lib/tst_cpu.c index e8ab34e..b492dc2 100644 --- a/lib/tst_cpu.c +++ b/lib/tst_cpu.c @@ -33,13 +33,35 @@ long tst_ncpus(void) return ncpus; } +#define KERNEL_MAX "/sys/devices/system/cpu/kernel_max" + long tst_ncpus_max(void) { long ncpus_max = -1; + struct stat buf; + + /* sched_getaffinity() and sched_setaffinity() cares about number of + * possible CPUs the OS or hardware can support, which can be larger + * than what sysconf(_SC_NPROCESSORS_CONF) currently provides + * (by enumarating /sys/devices/system/cpu/cpu* entries). + * + * Use /sys/devices/system/cpu/kernel_max, if available. This + * represents NR_CPUS-1, a compile time option which specifies + * "maximum number of CPUs which this kernel will support". + * This should provide cpu mask size large enough for any purposes. */ + if (stat(KERNEL_MAX, &buf) == 0) { + SAFE_FILE_SCANF(NULL, KERNEL_MAX, "%ld", &ncpus_max); + /* this is maximum CPU index allowed by the kernel + * configuration, so # of cpus allowed by config is +1 */ + ncpus_max++; + } else { + /* fall back to _SC_NPROCESSORS_CONF */ #ifdef _SC_NPROCESSORS_CONF - ncpus_max = SAFE_SYSCONF(NULL, _SC_NPROCESSORS_CONF); + ncpus_max = SAFE_SYSCONF(NULL, _SC_NPROCESSORS_CONF); #else - tst_brkm(TBROK, NULL, "could not determine number of CPUs configured"); + tst_brkm(TBROK, NULL, "could not determine number of CPUs" + " configured"); #endif + } return ncpus_max; } -- 1.7.1 ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] tst_ncpus_max: use kernel_max if available 2014-08-26 10:01 [LTP] [PATCH] tst_ncpus_max: use kernel_max if available Jan Stancek @ 2014-08-26 10:06 ` chrubis [not found] ` <1144259951.13045166.1409048187591.JavaMail.zimbra@redhat.com> 0 siblings, 1 reply; 7+ messages in thread From: chrubis @ 2014-08-26 10:06 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list Hi! > sched_getaffinity() and sched_setaffinity() cares about number of possible > CPUs the OS or hardware can support, which can be larger than what > sysconf(_SC_NPROCESSORS_CONF) currently provides (by enumarating > /sys/devices/system/cpu/cpu* entries). > > Use /sys/devices/system/cpu/kernel_max, if available. This represents > NR_CPUS-1, a compile time option which specifies "maximum number of CPUs > which this kernel will support". This should give us cpu mask size > large enough for any purposes. > > If the kernel_max sysfs file is not available, fall back to > _SC_NPROCESSORS_CONF. Looks good to me, acked. Is this last failure that needed to be fixed before the release or are there any more? -- Cyril Hrubis chrubis@suse.cz ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <1144259951.13045166.1409048187591.JavaMail.zimbra@redhat.com>]
* Re: [LTP] [PATCH] tst_ncpus_max: use kernel_max if available [not found] ` <1144259951.13045166.1409048187591.JavaMail.zimbra@redhat.com> @ 2014-08-26 10:55 ` chrubis [not found] ` <1485901937.13089374.1409051869026.JavaMail.zimbra@redhat.com> 0 siblings, 1 reply; 7+ messages in thread From: chrubis @ 2014-08-26 10:55 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list Hi! > These two are still open / under discussion: > [PATCH] sbrk02: check for ret code in setup() > [PATCH] mmap15: don't fail if mmap returns EINVAL > > mmap15 looks like old issue, so it could wait after release. Agreed. > sbrk02 can loop indefinitely in setup(), which is worse IMO. Ok. So the issue there is that sbrk() does not fail in setup() because the increment overflows. Does it work if we stop increasing the increment before that happen? Or does sbrk() fails to fail there? -- Cyril Hrubis chrubis@suse.cz ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <1485901937.13089374.1409051869026.JavaMail.zimbra@redhat.com>]
* Re: [LTP] [PATCH] tst_ncpus_max: use kernel_max if available [not found] ` <1485901937.13089374.1409051869026.JavaMail.zimbra@redhat.com> @ 2014-08-26 11:24 ` chrubis [not found] ` <555448176.13093369.1409052507826.JavaMail.zimbra@redhat.com> 0 siblings, 1 reply; 7+ messages in thread From: chrubis @ 2014-08-26 11:24 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list Hi! > It starts failing with -1, but never sets errno to ENOMEM, so it keeps looping > forever, waiting for condition that does not happen (which looks like genuine bug in sbrk). That indeed looks like a bug and in that case the original patch looks good to me. -- Cyril Hrubis chrubis@suse.cz ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <555448176.13093369.1409052507826.JavaMail.zimbra@redhat.com>]
* Re: [LTP] [PATCH] tst_ncpus_max: use kernel_max if available [not found] ` <555448176.13093369.1409052507826.JavaMail.zimbra@redhat.com> @ 2014-08-26 13:51 ` chrubis 2014-08-26 15:42 ` chrubis 0 siblings, 1 reply; 7+ messages in thread From: chrubis @ 2014-08-26 13:51 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list Hi! > Pushed - I'm not aware of any other outstanding issues for the release. I've pushed last patch that I've been working on, the fix for the kernel-devel configure check. And looking at my set of results there is last unexpected failure for read02 with /tmp on btrfs that fails to fail with O_DIRECT and unaligned buffers/lengths. But that may be a btrfs bug. I will look into this shortly and if no fix is found I would like to proceed with the release. -- Cyril Hrubis chrubis@suse.cz ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] tst_ncpus_max: use kernel_max if available 2014-08-26 13:51 ` chrubis @ 2014-08-26 15:42 ` chrubis 2014-08-27 7:41 ` chrubis 0 siblings, 1 reply; 7+ messages in thread From: chrubis @ 2014-08-26 15:42 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list Hi! > And looking at my set of results there is last unexpected failure for > read02 with /tmp on btrfs that fails to fail with O_DIRECT and unaligned > buffers/lengths. But that may be a btrfs bug. I will look into this > shortly and if no fix is found I would like to proceed with the release. And I've got an answer from David Sterba that btrfs fallbacks to regular I/O in this case. I will patch the testcase to take that into an account on btrfs and after that the release would get a green light from me as well. -- Cyril Hrubis chrubis@suse.cz ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] tst_ncpus_max: use kernel_max if available 2014-08-26 15:42 ` chrubis @ 2014-08-27 7:41 ` chrubis 0 siblings, 0 replies; 7+ messages in thread From: chrubis @ 2014-08-27 7:41 UTC (permalink / raw) To: Jan Stancek; +Cc: ltp-list Hi! > > And looking at my set of results there is last unexpected failure for > > read02 with /tmp on btrfs that fails to fail with O_DIRECT and unaligned > > buffers/lengths. But that may be a btrfs bug. I will look into this > > shortly and if no fix is found I would like to proceed with the release. > > And I've got an answer from David Sterba that btrfs fallbacks to regular > I/O in this case. I will patch the testcase to take that into an account > on btrfs and after that the release would get a green light from me as > well. Hmm I seem to start a debate whether this behavior is a bug or not. I guess that we can wait and see if it's settled by today and if not we can proceed with the release leaving the testcase as it is. -- Cyril Hrubis chrubis@suse.cz ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-08-27 7:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-26 10:01 [LTP] [PATCH] tst_ncpus_max: use kernel_max if available Jan Stancek
2014-08-26 10:06 ` chrubis
[not found] ` <1144259951.13045166.1409048187591.JavaMail.zimbra@redhat.com>
2014-08-26 10:55 ` chrubis
[not found] ` <1485901937.13089374.1409051869026.JavaMail.zimbra@redhat.com>
2014-08-26 11:24 ` chrubis
[not found] ` <555448176.13093369.1409052507826.JavaMail.zimbra@redhat.com>
2014-08-26 13:51 ` chrubis
2014-08-26 15:42 ` chrubis
2014-08-27 7:41 ` chrubis
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.