From: Rob Landley <rob@landley.net>
To: Alex Shi <alex.shi@intel.com>
Cc: Borislav Petkov <bp@amd64.org>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
arnd@arndb.de, rostedt@goodmis.org, fweisbec@gmail.com,
jeremy@goop.org, gregkh@linuxfoundation.org, riel@redhat.com,
luto@mit.edu, avi@redhat.com, len.brown@intel.com,
dhowells@redhat.com, fenghua.yu@intel.com, ak@linux.intel.com,
cpw@sgi.com, steiner@sgi.com, akpm@linux-foundation.org,
penberg@kernel.org, hughd@google.com, rientjes@google.com,
kosaki.motohiro@jp.fujitsu.com, n-horiguchi@ah.jp.nec.com,
paul.gortmaker@windriver.com, trenn@suse.de, tj@kernel.org,
oleg@redhat.com, axboe@kernel.dk, a.p.zijlstra@chello.nl,
kamezawa.hiroyu@jp.fujitsu.com, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/7] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range
Date: Thu, 10 May 2012 16:42:31 -0500 [thread overview]
Message-ID: <4FAC3647.8020203@landley.net> (raw)
In-Reply-To: <4FAB8169.7090809@intel.com>
On 05/10/2012 03:50 AM, Alex Shi wrote:
>>
>
>> Ok, question:
>>
>> we're comparing TLB size with the amount of pages mapped by this mm
>> struct. AFAICT, that doesn't mean that all those mapped pages do have
>> respective entries in the TLB, does it?
>>
>> If so, then the actual entries number is kinda inaccurate, no? We don't
>> really know how many TLB entries actually belong to this mm struct. Or am I
>> missing something?
>
> No, we can not know the exactly TLB entires for. But usually, when you
> process is doing the mprotect/munmap etc system call, your process has
> taken much of memory and already filled lots of TLB entries.
$ strace true 2>&1 | grep mprotect
mprotect(0x7f67a934b000, 2093056, PROT_NONE) = 0
mprotect(0x7f67a954a000, 16384, PROT_READ) = 0
mprotect(0x607000, 4096, PROT_READ) = 0
mprotect(0x7f67a9773000, 4096, PROT_READ) = 0
This appears to be part of glibc process setup. Define "usually".
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
next prev parent reply other threads:[~2012-05-10 21:42 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-10 5:00 [PATCH v4 0/7] tlb flush optimization Alex Shi
2012-05-10 5:00 ` [PATCH v4 1/7] x86/tlb: unify TLB_FLUSH_ALL definition Alex Shi
2012-05-10 18:46 ` Rob Landley
2012-05-11 18:33 ` H. Peter Anvin
2012-05-10 5:00 ` [PATCH v4 2/7] x86/tlb_info: get last level TLB entry number of CPU Alex Shi
2012-05-10 14:43 ` Borislav Petkov
2012-05-11 0:33 ` Alex Shi
2012-05-10 15:58 ` Borislav Petkov
2012-05-11 0:38 ` Alex Shi
2012-05-10 5:00 ` [PATCH v4 3/7] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
2012-05-10 7:53 ` Borislav Petkov
2012-05-10 8:50 ` Alex Shi
2012-05-10 21:42 ` Rob Landley [this message]
2012-05-10 8:42 ` Borislav Petkov
2012-05-10 9:04 ` Alex Shi
2012-05-12 8:01 ` Alex Shi
2012-05-13 11:13 ` Borislav Petkov
2012-05-15 1:06 ` Alex Shi
2012-05-15 10:33 ` Borislav Petkov
2012-05-15 11:16 ` Peter Zijlstra
2012-05-15 11:56 ` Borislav Petkov
2012-05-15 12:00 ` Peter Zijlstra
2012-05-15 13:58 ` Alex Shi
2012-05-10 5:00 ` [PATCH v4 4/7] x86/tlb: fall back to flush all when meet a THP large page Alex Shi
2012-05-10 9:29 ` Peter Zijlstra
2012-05-10 10:40 ` Borislav Petkov
2012-05-11 0:44 ` Alex Shi
2012-05-11 9:03 ` Peter Zijlstra
2012-05-11 16:28 ` Andrea Arcangeli
2012-05-12 7:58 ` Alex Shi
2012-05-10 5:00 ` [PATCH v4 5/7] x86/tlb: add tlb flush all factor for specific CPU Alex Shi
2012-05-10 9:35 ` Peter Zijlstra
2012-05-11 0:47 ` Alex Shi
2012-05-10 9:37 ` Peter Zijlstra
2012-05-11 0:48 ` Alex Shi
2012-05-10 9:38 ` Peter Zijlstra
2012-05-10 10:42 ` Borislav Petkov
2012-05-11 0:50 ` Alex Shi
2012-05-11 0:49 ` Alex Shi
2012-05-11 9:04 ` Peter Zijlstra
2012-05-11 9:04 ` Peter Zijlstra
2012-05-11 12:51 ` Alex Shi
2012-05-10 5:00 ` [PATCH v4 6/7] x86/tlb: optimizing flush_tlb_mm Alex Shi
2012-05-10 8:27 ` Peter Zijlstra
2012-05-10 5:00 ` [PATCH v4 7/7] x86/tlb: add tlb_flushall_factor into sysfs for user testing/tuning Alex Shi
2012-05-10 8:27 ` Borislav Petkov
2012-05-11 0:52 ` Alex Shi
2012-05-11 9:51 ` Borislav Petkov
2012-05-11 12:53 ` Alex Shi
2012-05-10 15:13 ` Greg KH
2012-05-11 0:59 ` Alex Shi
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=4FAC3647.8020203@landley.net \
--to=rob@landley.net \
--cc=a.p.zijlstra@chello.nl \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=arnd@arndb.de \
--cc=avi@redhat.com \
--cc=axboe@kernel.dk \
--cc=bp@amd64.org \
--cc=cpw@sgi.com \
--cc=dhowells@redhat.com \
--cc=fenghua.yu@intel.com \
--cc=fweisbec@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=jeremy@goop.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@mit.edu \
--cc=mingo@redhat.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=oleg@redhat.com \
--cc=paul.gortmaker@windriver.com \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=trenn@suse.de \
--cc=viro@zeniv.linux.org.uk \
/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 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.