search for: next_cpu

...2017-08-01 09:28:24 -0600 1142) */ 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* Is this a known issue? Christian

...2017-08-01 09:28:24 -0600 1142) */ 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* Is this a known issue? Christian

...01 09:28:24 -0600 1142) */ >> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* > > Did you really try to figure out when the code that reported the warning > was introduced? I think that warning was int...

...01 09:28:24 -0600 1142) */ >> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* > > Did you really try to figure out when the code that reported the warning > was introduced? I think that warning was int...

...0 1142) */ >>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>> >>> Did you really try to figure out when the code that reported the warning >>> was i...

...0 1142) */ >>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>> >>> Did you really try to figure out when the code that reported the warning >>> was i...

...gt;>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>>>> >>>>> Did you really try to figure out when the code that reporte...

...gt;>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>>>> >>>>> Did you really try to figure out when the code that reporte...

...2017-08-01 09:28:24 -0600 1142) */ > 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && > 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); > 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) > b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* Did you really try to figure out when the code that reported the warning was introduced? I think that warning was introduced through the fol...

...:24 -0600 1142) */ >>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >> >> Did you really try to figure out when the code that reported the warning >> was introduced? I think t...

...gt;>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>>>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>>>>> >>>>>> Did you really try to figure out when the c...

...*/ >>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>>> >>>> Did you really try to figure out when the code that reported the warning &g...

...rcpu freelist does have tags. > > + */ > > + unsigned long *cpus_have_tags; > > Why not cpumask_t? I hadn't encountered it before - looks like it's probably what I want. I don't see any explanation for the parallel set of operations for working on cpumasks - e.g. next_cpu()/cpumask_next(). For now I'm going with the cpumask_* versions, is that what I want?o If you can have a look at the fixup patch that'll be most appreciated. > > + struct { > > + spinlock_t lock; > > + /* > > + * When we go to steal tags from another cpu (see...

...gt;>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>>>>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>>>>>> >>>>>>> Did you really try to figur...

...gt;>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) && >>>>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu)); >>>>>>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145) >>>>>>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /* >>>>>>> >>>>>>> Did you really try to figur...

On Fri, 16 Aug 2013 23:09:06 +0000 "Nicholas A. Bellinger" <nab at linux-iscsi.org> wrote: > From: Kent Overstreet <kmo at daterainc.com> > > Percpu frontend for allocating ids. With percpu allocation (that works), > it's impossible to guarantee it will always be possible to allocate all > nr_tags - typically, some will be stuck on a remote percpu

On Fri, 16 Aug 2013 23:09:06 +0000 "Nicholas A. Bellinger" <nab at linux-iscsi.org> wrote: > From: Kent Overstreet <kmo at daterainc.com> > > Percpu frontend for allocating ids. With percpu allocation (that works), > it's impossible to guarantee it will always be possible to allocate all > nr_tags - typically, some will be stuck on a remote percpu

I am confused with a problem: I have a blade with 64 physical CPUs and 64G physical RAM, and defined only one VM with 1 CPU and 40G RAM. For the first time I started the VM, it just took 3s, But for the second starting it took 30s. After studied it by printing log, I have located a place in the hypervisor where cost too much time, occupied 98% of the whole starting time. xen/common/page_alloc.c

Hi all, this is the long awaited patch series to add xen device model support in qemu; the main author is Anthony Perard. Developing this series we tried to come up with the cleanest possible solution from the qemu point of view, limiting the amount of changes to common code as much as possible. The end result still requires a couple of hooks in piix_pci but overall the impact should be very