Displaying 11 results from an estimated 11 matches for "cpumask_any_but".
2019 Jul 19
0
[PATCH v3 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
...freed_tables,
new_tlb_gen);
- if (mm == this_cpu_read(cpu_tlbstate.loaded_mm)) {
+ /*
+ * flush_tlb_multi() is not optimized for the common case in which only
+ * a local TLB flush is needed. Optimize this use-case by calling
+ * flush_tlb_func_local() directly in this case.
+ */
+ if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids) {
+ flush_tlb_multi(mm_cpumask(mm), info);
+ } else if (mm == this_cpu_read(cpu_tlbstate.loaded_mm)) {
lockdep_assert_irqs_enabled();
local_irq_disable();
flush_tlb_func_local(info);
local_irq_enable();
}
- if (cpumask_any_but(mm_cpumask(mm), c...
2019 Jul 02
0
[PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
...=
+ (mm == this_cpu_read(cpu_tlbstate.loaded_mm)) &&
+ mm != &init_mm);
+
+ /*
+ * flush_tlb_multi() is not optimized for the common case in which only
+ * a local TLB flush is needed. Optimize this use-case by calling
+ * flush_tlb_func_local() directly in this case.
+ */
+ if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids) {
+ flush_tlb_multi(mm_cpumask(mm), info);
+ } else {
lockdep_assert_irqs_enabled();
local_irq_disable();
flush_tlb_func_local(info);
local_irq_enable();
}
- if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids)
- flush_tlb_others(mm_cpuma...
2019 Jul 02
2
[PATCH v2 0/9] x86: Concurrent TLB flushes
Currently, local and remote TLB flushes are not performed concurrently,
which introduces unnecessary overhead - each INVLPG can take 100s of
cycles. This patch-set allows TLB flushes to be run concurrently: first
request the remote CPUs to initiate the flush, then run it locally, and
finally wait for the remote CPUs to finish their work.
In addition, there are various small optimizations to avoid
2019 Jul 19
5
[PATCH v3 0/9] x86: Concurrent TLB flushes
[ Cover-letter is identical to v2, including benchmark results,
excluding the change log. ]
Currently, local and remote TLB flushes are not performed concurrently,
which introduces unnecessary overhead - each INVLPG can take 100s of
cycles. This patch-set allows TLB flushes to be run concurrently: first
request the remote CPUs to initiate the flush, then run it locally, and
finally wait for
2009 Jan 07
4
[PATCH 3/5] cpumask: convert misc driver functions
An embedded and charset-unspecified text was scrubbed...
Name: cpumask:convert-drivers.patch
Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20090107/f459eb35/attachment.txt
2009 Jan 07
4
[PATCH 3/5] cpumask: convert misc driver functions
An embedded and charset-unspecified text was scrubbed...
Name: cpumask:convert-drivers.patch
Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20090107/f459eb35/attachment.txt
2019 May 25
3
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
...lush_tlb_multi() can handle a single CPU, but it is
+ * suboptimal if the local TLB should be flushed, and therefore should
+ * not be used in such case. Check that it is not used in such case,
+ * and use this assumption for tracing and accounting of remote TLB
+ * flushes.
+ */
+ VM_WARN_ON(!cpumask_any_but(cpumask, smp_processor_id()));
+
+ /*
+ * Do accounting and tracing. Note that there are (and have always been)
+ * cases in which a remote TLB flush will be traced, but eventually
+ * would not happen.
+ */
count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
if (info->end == TLB_FLUSH_ALL)
trac...
2019 May 25
3
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
...lush_tlb_multi() can handle a single CPU, but it is
+ * suboptimal if the local TLB should be flushed, and therefore should
+ * not be used in such case. Check that it is not used in such case,
+ * and use this assumption for tracing and accounting of remote TLB
+ * flushes.
+ */
+ VM_WARN_ON(!cpumask_any_but(cpumask, smp_processor_id()));
+
+ /*
+ * Do accounting and tracing. Note that there are (and have always been)
+ * cases in which a remote TLB flush will be traced, but eventually
+ * would not happen.
+ */
count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
if (info->end == TLB_FLUSH_ALL)
trac...
2019 May 31
2
[RFC PATCH v2 04/12] x86/mm/tlb: Flush remote and local TLBs concurrently
...lush_tlb_multi() can handle a single CPU, but it is
+ * suboptimal if the local TLB should be flushed, and therefore should
+ * not be used in such case. Check that it is not used in such case,
+ * and use this assumption for tracing and accounting of remote TLB
+ * flushes.
+ */
+ VM_WARN_ON(!cpumask_any_but(cpumask, smp_processor_id()));
+
+ /*
+ * Do accounting and tracing. Note that there are (and have always been)
+ * cases in which a remote TLB flush will be traced, but eventually
+ * would not happen.
+ */
count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
if (info->end == TLB_FLUSH_ALL)
trac...
2019 May 31
2
[RFC PATCH v2 04/12] x86/mm/tlb: Flush remote and local TLBs concurrently
...lush_tlb_multi() can handle a single CPU, but it is
+ * suboptimal if the local TLB should be flushed, and therefore should
+ * not be used in such case. Check that it is not used in such case,
+ * and use this assumption for tracing and accounting of remote TLB
+ * flushes.
+ */
+ VM_WARN_ON(!cpumask_any_but(cpumask, smp_processor_id()));
+
+ /*
+ * Do accounting and tracing. Note that there are (and have always been)
+ * cases in which a remote TLB flush will be traced, but eventually
+ * would not happen.
+ */
count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
if (info->end == TLB_FLUSH_ALL)
trac...
2009 Jan 10
51
Xen with dom0 pvops on ultra-recent "git tip" kernel on x86_64
Hi everyone,
I am very excited to see that dom0 pvops is finally coming close to
working, so I wanted to give it a try.
>From the description it was not clear to me which kernel to chose as
base for the patches.hg, so I took the latest (that was ~ 2 weeks ago)
kernel on git.kernel.org I could find (post-2.6.28 git tip at that
point).
I managed to more or less apply all of the patches in the