search for: nr_cpus

Testing on an 8-node 128-way NUMA machine has exposed a problem with Xen''s nr_cpus calculation. In this case, since Xen cuts off recognized CPUs at 32, the machine appears to have 16 CPUs on the first and second nodes and none on the remaining nodes. Given this asymmetry, the calculation of sockets_per_node (which is later used to calculate nr_cpus) is incorrect: pi->sock...

This will allow userspace to reason with the total number of CPUs, not just the current number of online CPUs. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Once Xen calculates nr_nodes properly, all nr_cpu calculations based on nr_nodes * sockets_per_node * cores_per_socket * threads_per_core are broken. The easy fix is to replace those calculations with a new field, nr_cpus in physinfo which is calculated by num_online_cpus(). This patch does so and attempts to change all users over to nr_cpus field in physinfo. This patch touches arch/ia64/xen/dom0_ops.c, but I''ve not done any IA64 testing with this patch applied. -- Ryan Harper Software Engineer; Linux...

Il 07/07/2014 16:35, Peter Zijlstra ha scritto: > On Wed, Jun 18, 2014 at 01:39:52PM +0200, Paolo Bonzini wrote: >> Il 15/06/2014 14:47, Peter Zijlstra ha scritto: >>> >>> - for (;;) { >>> - new = (val & ~_Q_PENDING_MASK) | _Q_LOCKED_VAL; >>> - >>> - old = atomic_cmpxchg(&lock->val, val, new); >>> - if (old == val)

...md.com> diff -r b4278beaf354 xen/arch/x86/platform_hypercall.c --- a/xen/arch/x86/platform_hypercall.c Wed Oct 17 13:12:03 2007 +0100 +++ b/xen/arch/x86/platform_hypercall.c Thu Oct 18 16:07:53 2007 -0500 @@ -295,14 +295,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe { uint32_t i, nr_cpus; uint64_t idletime; + uint64_t totaltime; struct vcpu *v; XEN_GUEST_HANDLE(uint64_t) idletimes; + XEN_GUEST_HANDLE(uint64_t) totaltimes; ret = -ENOSYS; if ( cpufreq_controller != FREQCTL_dom0_kernel ) break; guest_from_co...

Il 07/07/2014 16:35, Peter Zijlstra ha scritto: > On Wed, Jun 18, 2014 at 01:39:52PM +0200, Paolo Bonzini wrote: >> Il 15/06/2014 14:47, Peter Zijlstra ha scritto: >>> >>> - for (;;) { >>> - new = (val & ~_Q_PENDING_MASK) | _Q_LOCKED_VAL; >>> - >>> - old = atomic_cmpxchg(&lock->val, val, new); >>> - if (old == val)

ext2 & ext3 lists, Attatched is a patch that allows ext2 and ext3 to link correctly when the kernel is configured with a large NR_CPUS. We do have an immediate need for this patch. Any opinions on this? The per-cpu lists are causing the kmalloc to fail due to allocating more than the max. thanks mh -- Martin Hicks Wild Open Source Inc. mort@wildopensource.com 613-266-2296 # This is a BitKeeper generated...

...> Unlike the change in patch 4, clear_pending_set_locked doesn't change how > qspinlock moves from a state to the next. True, but its where we start to break up into smaller functions. And the only reason we break them out is because we'll get different implementations depending on NR_CPUS. So we can view the breakout of xchg_tail and clear_and_set_pending as preparatory work for introducing the NR_CPUS thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <...

From: Peter Zijlstra <peterz at infradead.org> When we allow for a max NR_CPUS < 2^14 we can optimize the pending wait-acquire and the xchg_tail() operations. By growing the pending bit to a byte, we reduce the tail to 16bit. This means we can use xchg16 for the tail part and do away with all the repeated compxchg() operations. This in turn allows us to unconditionally a...

...mere E7-8837 and SandyBridge i5-2500 to the vpmu list Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> changeset: 23802:bb9b81008733 user: Laszlo Ersek <lersek@redhat.com> date: Wed Aug 31 15:16:14 2011 +0100 x86: Increase the default NR_CPUS to 256 Changeset 21012:ef845a385014 bumped the default to 128 about one and a half years ago. Increase it now to 256, as systems with eg. 160 logical CPUs are becoming (have become) common. Signed-off-by: Laszlo Ersek <lersek@redhat.com> changeset: 23801:...

On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: > @@ -48,6 +53,9 @@ > * We can further change the first spinner to spin on a bit in the lock word > * instead of its node; whereby avoiding the need to carry a node from lock to > * unlock, and preserving API. > + * > + * N.B. The current implementation only supports architectures that allow > + * atomic

On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: > @@ -48,6 +53,9 @@ > * We can further change the first spinner to spin on a bit in the lock word > * instead of its node; whereby avoiding the need to carry a node from lock to > * unlock, and preserving API. > + * > + * N.B. The current implementation only supports architectures that allow > + * atomic

When we allow for a max NR_CPUS < 2^14 we can optimize the pending wait-acquire and the xchg_tail() operations. By growing the pending bit to a byte, we reduce the tail to 16bit. This means we can use xchg16 for the tail part and do away with all the repeated compxchg() operations. This in turn allows us to unconditionally a...

On Sun, Jun 15, 2014 at 02:47:02PM +0200, Peter Zijlstra wrote: > From: Peter Zijlstra <peterz at infradead.org> > > When we allow for a max NR_CPUS < 2^14 we can optimize the pending > wait-acquire and the xchg_tail() operations. > > By growing the pending bit to a byte, we reduce the tail to 16bit. > This means we can use xchg16 for the tail part and do away with all > the repeated compxchg() operations. > > This in...

On Sun, Jun 15, 2014 at 02:47:02PM +0200, Peter Zijlstra wrote: > From: Peter Zijlstra <peterz at infradead.org> > > When we allow for a max NR_CPUS < 2^14 we can optimize the pending > wait-acquire and the xchg_tail() operations. > > By growing the pending bit to a byte, we reduce the tail to 16bit. > This means we can use xchg16 for the tail part and do away with all > the repeated compxchg() operations. > > This in...

On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: > +#if !defined(__LITTLE_ENDIAN) && !defined(__BIG_ENDIAN) > +#error "Missing either LITTLE_ENDIAN or BIG_ENDIAN definition." > +#endif This seems entirely superfluous, I don't think a kernel build will go anywhere if either is missing.

On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: > +static __always_inline void > +clear_pending_set_locked(struct qspinlock *lock, u32 val) > +{ > + struct __qspinlock *l = (void *)lock; > + > + ACCESS_ONCE(l->locked_pending) = 1; > +} > @@ -157,8 +251,13 @@ static inline int trylock_pending(struct qspinlock *lock, u32 *pval) > * we're pending,

On 04/17/2014 11:58 AM, Peter Zijlstra wrote: > On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: >> +static __always_inline void >> +clear_pending_set_locked(struct qspinlock *lock, u32 val) >> +{ >> + struct __qspinlock *l = (void *)lock; >> + >> + ACCESS_ONCE(l->locked_pending) = 1; >> +} >> @@ -157,8 +251,13 @@ static inline int

On 04/17/2014 11:56 AM, Peter Zijlstra wrote: > On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: >> +struct __qspinlock { >> + union { >> + atomic_t val; >> + struct { >> +#ifdef __LITTLE_ENDIAN >> + u16 locked_pending; >> + u16 tail; >> +#else >> + u16 tail; >> + u16 locked_pending; >> +#endif >> +

On 04/18/2014 04:27 AM, Peter Zijlstra wrote: > On Thu, Apr 17, 2014 at 05:46:27PM -0400, Waiman Long wrote: >> On 04/17/2014 11:56 AM, Peter Zijlstra wrote: >>> On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote: >>>> +struct __qspinlock { >>>> + union { >>>> + atomic_t val; > char bytes[4]; > >>>> + struct {