All of lore.kernel.org
 help / color / mirror / Atom feed
* [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

* 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

* 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

* 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.