All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: davidm@hpl.hp.com
Cc: Jack Steiner <steiner@sgi.com>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] - Reduce TLB flushing during process migration
Date: Wed, 07 Jul 2004 09:52:30 -0400	[thread overview]
Message-ID: <40EC001E.5020508@comcast.net> (raw)
In-Reply-To: <16619.15708.487344.93894@napali.hpl.hp.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



David Mosberger wrote:
|>>>>>On Fri, 2 Jul 2004 12:39:05 -0500, Jack Steiner <steiner@sgi.com>
said:
|
| Well, then it's not a true no-op.  The other no-ops are all for
| init-type stuff, so they're not at all performance critical.  Even
| when compiling a non-generic kernel, those no-op functions will be
| called.  This is really a limitation in the current machvec-scheme.  I
| think what we need is a way to explicitly declare a no-op callback,
| such that it can be optimized away completely for platforms that don't
| need it.  Perhaps there could be something along the lines of:
|
| #ifdef CONFIG_IA64_GENERIC
| # define machvec_noop(noop_function)	noop_function
| #else
| # define machvec_noop(noop_function)	/* empty */
| #endif
|

?????

1.  At any -O level, I'd assume the loop optimizer or something along
those lines would see a 1 iteration loop and remove the actual loop
instruction:

MOV CX,1 ; 1 iteration
...
LOOP ; Just DEC CX and falls through

In the pseudocode above, we can clearly see that the MOV and the LOOP
perform no real function.  The optimizer *should* AFAIK notice that a
do{...}while(0) generates useless looping instructions and thus prevent
those instructions from being generated.  In the case of do{}while(0),
this generates 0 instructions.

2.  A function call to a no-op is an unoptimizable and excessive
overhead compared to do{}while(0) in most cases; the no-op would need to
be inline assembly, thus maintained for each arch, AFAIK.

3.  An actual no-op instruction still needs to be iterated past by the
processor.  Usually, no-op is only generated by the compiler for
padding, AFAIK; and even then, there's some kind of jump before the load
of no-ops to get past them.  I don't know if inline assembly is
optimized out; but I would assume not.

4.  I don't think /* empty */; is an error; but the following block has
problems:

if (foo)
~  ;
else
~  do_something();

So, we need something that gets parsed to exactly nothing.

Thus, as far as I can understand, because we use -O2 or -Os, we will
always get exactly 0 instructions from do{}while(0).  This is the best
solution to the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA7AAchDd4aOud5P8RAtYeAJ9rdKb4ZE4KPT15C2O8TvlrL82A/gCdFm2b
fslXb9dDCj6ccW7tSFpogzw=
=v4oX
-----END PGP SIGNATURE-----

  reply	other threads:[~2004-07-07 13:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-23 14:38 [PATCH] - Reduce TLB flushing during process migration Jack Steiner
2004-06-23 21:33 ` Andrew Morton
2004-06-24 12:55   ` Jack Steiner
2004-06-24 18:44     ` Andrew Morton
2004-06-25 14:23       ` Jack Steiner
2004-06-26  5:10   ` David Mosberger
2004-07-02 17:39     ` Jack Steiner
2004-07-07  0:01       ` David Mosberger
2004-07-07 13:52         ` John Richard Moser [this message]
2004-07-07 15:48         ` Jack Steiner
2004-07-07 18:30           ` David Mosberger
  -- strict thread matches above, loose matches on Subject: below --
2004-07-11 13:47 Jack Steiner
2004-07-12 21:28 ` David Mosberger

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=40EC001E.5020508@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=akpm@osdl.org \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steiner@sgi.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 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.