From: Alex Shi <alex.shi@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: borislav.petkov@amd.com, arnd@arndb.de,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
akinobu.mita@gmail.com, eric.dumazet@gmail.com,
fweisbec@gmail.com, rostedt@goodmis.org, hughd@google.com,
jeremy@goop.org, len.brown@intel.com, tony.luck@intel.com,
yongjie.ren@intel.com, kamezawa.hiroyu@jp.fujitsu.com,
seto.hidetoshi@jp.fujitsu.com, penberg@kernel.org,
yinghai@kernel.org, tglx@linutronix.de,
akpm@linux-foundation.org, ak@linux.intel.com, luto@mit.edu,
avi@redhat.com, dhowells@redhat.com, mingo@redhat.com,
riel@redhat.com, cpw@sgi.com, steiner@sgi.com,
linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
hpa@zytor.com
Subject: Re: [PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings of SMT
Date: Thu, 24 May 2012 17:02:20 +0800 [thread overview]
Message-ID: <4FBDF91C.7050902@intel.com> (raw)
In-Reply-To: <4FBE11EB0200007800085BD0@nat28.tlf.novell.com>
>>
>> I just measured the cost of this function on my Romely EP(32 LCPUs) with
>> cpumask_t and NR_CPUS = 32/256/512/4096, the cost are similar with
>> 256/512/4096 and that increased about 20% time cost from 32.
>>
>> I also tried to use cpumask_var_t and alloc it in heap(use
>> CPUMASK_OFFSTACK), actually, it cost same time with cpumask_t in stack.
>> But, the allocation bring another big cost. So, I use cpumask_t in stack.
>> The performance gain data in commit log is getting with NR_CPUS = 256.
>
> Perhaps using a per-CPU cpumask would be the better choice here
See.
> (I can't see how preemption could validly be enabled when this
> code is utilized).
Sorry, What's your meaning here?, the function is always in pre-empt
safe mode.
>
> Jan
>
next prev parent reply other threads:[~2012-05-24 9:04 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-23 14:15 [PATCH v7 0/8] x86 tlb optimisations Alex Shi
2012-05-23 14:15 ` [PATCH v7 1/8] x86/tlb_info: get last level TLB entry number of CPU Alex Shi
2012-05-23 14:15 ` [PATCH v7 2/8] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
2012-05-23 14:51 ` Jan Beulich
2012-05-24 6:41 ` Alex Shi
2012-05-24 8:12 ` Jan Beulich
2012-05-24 8:55 ` Alex Shi
2012-05-24 9:44 ` Jan Beulich
2012-05-24 14:36 ` Alex Shi
2012-05-25 2:43 ` Alex Shi
2012-05-23 14:15 ` [PATCH v7 3/8] x86/tlb: fall back to flush all when meet a THP large page Alex Shi
2012-05-23 14:15 ` [PATCH v7 4/8] x86/tlb: add tlb_flushall_shift for specific CPU Alex Shi
2012-05-23 14:15 ` [PATCH v7 5/8] x86/tlb: enable tlb flush range support for generic mmu and x86 Alex Shi
2012-05-23 14:15 ` [PATCH v7 6/8] x86/tlb: add tlb_flushall_shift knob into debugfs Alex Shi
2012-05-23 14:15 ` [PATCH v7 7/8] x86/tlb: replace INVALIDATE_TLB_VECTOR by CALL_FUNCTION_VECTOR Alex Shi
2012-05-23 14:15 ` [PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings of SMT Alex Shi
2012-05-23 15:05 ` Jan Beulich
2012-05-23 17:09 ` Peter Zijlstra
2012-05-23 17:15 ` Peter Zijlstra
2012-05-24 1:46 ` Andrew Lutomirski
2012-05-24 5:12 ` Alex Shi
2012-05-24 6:04 ` Borislav Petkov
2012-05-24 7:40 ` Peter Zijlstra
2012-05-24 13:19 ` Andrew Lutomirski
2012-05-24 13:23 ` Peter Zijlstra
2012-05-24 13:39 ` Arjan van de Ven
2012-05-24 13:54 ` Alex Shi
2012-05-24 14:18 ` Arjan van de Ven
2012-05-24 14:32 ` Alex Shi
2012-05-24 15:03 ` H. Peter Anvin
2012-05-25 0:24 ` Alex Shi
2012-05-24 16:08 ` Arjan van de Ven
2012-05-25 0:28 ` Alex Shi
2012-05-25 0:46 ` Arjan van de Ven
2012-05-24 8:32 ` Alex Shi
2012-05-24 8:42 ` Peter Zijlstra
2012-05-24 8:48 ` Alex Shi
2012-05-24 11:35 ` Rusty Russell
2012-05-24 14:03 ` Alex Shi
2012-05-24 9:27 ` Alex Shi
2012-05-24 9:42 ` Peter Zijlstra
2012-05-24 9:46 ` Jan Beulich
2012-05-24 14:06 ` Alex Shi
2012-05-24 8:43 ` Peter Zijlstra
2012-05-24 8:48 ` Jan Beulich
2012-05-24 9:02 ` Alex Shi [this message]
2012-05-24 9:45 ` Jan Beulich
2012-05-24 15:04 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBDF91C.7050902@intel.com \
--to=alex.shi@intel.com \
--cc=JBeulich@suse.com \
--cc=a.p.zijlstra@chello.nl \
--cc=ak@linux.intel.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=avi@redhat.com \
--cc=borislav.petkov@amd.com \
--cc=cpw@sgi.com \
--cc=dhowells@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=jeremy@goop.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@mit.edu \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yinghai@kernel.org \
--cc=yongjie.ren@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox