From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265000AbUGGNwe (ORCPT ); Wed, 7 Jul 2004 09:52:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265007AbUGGNwe (ORCPT ); Wed, 7 Jul 2004 09:52:34 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.85]:32216 "EHLO rwcrmhc12.comcast.net") by vger.kernel.org with ESMTP id S265000AbUGGNwb (ORCPT ); Wed, 7 Jul 2004 09:52:31 -0400 Message-ID: <40EC001E.5020508@comcast.net> Date: Wed, 07 Jul 2004 09:52:30 -0400 From: John Richard Moser User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040630) X-Accept-Language: en-us, en MIME-Version: 1.0 To: davidm@hpl.hp.com CC: Jack Steiner , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] - Reduce TLB flushing during process migration References: <20040623143844.GA15670@sgi.com> <20040623143318.07932255.akpm@osdl.org> <16605.1322.355489.223220@napali.hpl.hp.com> <20040702173905.GA18884@sgi.com> <16619.15708.487344.93894@napali.hpl.hp.com> In-Reply-To: <16619.15708.487344.93894@napali.hpl.hp.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Mosberger wrote: |>>>>>On Fri, 2 Jul 2004 12:39:05 -0500, Jack Steiner 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-----