From: Denis Vlasenko <vda@ilport.com.ua>
To: <cutaway@bellsouth.net>, "Coywolf Qi Hunt" <coywolf@gmail.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] exit_thread() speedups in x86 process.c
Date: Tue, 14 Jun 2005 10:43:03 +0300 [thread overview]
Message-ID: <200506141043.03502.vda@ilport.com.ua> (raw)
In-Reply-To: <002401c57099$394f9070$2800000a@pc365dualp2>
On Tuesday 14 June 2005 07:26, cutaway@bellsouth.net wrote:
> The problem with that approach is GCC would still just relocate the push/pop
> block to the bottom of the function. This means you won't be likely to pick
> up anything useful in L1 or L2 as the function exits normally - in fact
> you'd typically be guaranteed to be picking up a partial line of gorp that
> is completely worthless later on.
>
> This is one of my issues with the notion of unlikely() being smoothed on
> everywhere like Bondo<g> - it also makes it "unlikely" that you'll get any
> serendipitous L1/L2 advantages that could be had by locating related
> functions next to each other.
>
> When you take the unlikely stuff completely out of line in a seperate
> functions located elsewhere, the mainline code can make better use of the
> caches. The Intel parts thrive on L1 hits and die if they're not getting
> them.
That's exactly what compiler can do by itself. The fact that currently
it isn't smart enough to od it means that it has to be improved.
You propose that people have to do compiler's job.
--
vda
next prev parent reply other threads:[~2005-06-14 7:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-14 1:16 cutaway
2005-06-14 3:08 ` Coywolf Qi Hunt
2005-06-14 4:26 ` cutaway
2005-06-14 7:43 ` Denis Vlasenko [this message]
2005-06-22 5:48 Chuck Ebbert
2005-06-22 8:41 ` cutaway
2005-07-02 2:57 Chuck Ebbert
2005-07-02 11:56 ` Denis Vlasenko
2005-07-03 19:59 ` cutaway
[not found] <200507012258_MC3-1-A340-3A81@compuserve.com.suse.lists.linux.kernel>
[not found] ` <200507021456.40667.vda@ilport.com.ua.suse.lists.linux.kernel>
2005-07-03 16:05 ` Andi Kleen
2005-07-05 18:30 William Cohen
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=200506141043.03502.vda@ilport.com.ua \
--to=vda@ilport.com.ua \
--cc=coywolf@gmail.com \
--cc=cutaway@bellsouth.net \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®