From: David Mosberger <davidm@napali.hpl.hp.com>
To: Jack Steiner <steiner@sgi.com>
Cc: davidm@hpl.hp.com, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] - Reduce TLB flushing during process migration
Date: Tue, 6 Jul 2004 17:01:32 -0700 [thread overview]
Message-ID: <16619.15708.487344.93894@napali.hpl.hp.com> (raw)
In-Reply-To: <20040702173905.GA18884@sgi.com>
>>>>> On Fri, 2 Jul 2004 12:39:05 -0500, Jack Steiner <steiner@sgi.com> said:
>> Also, my preference would be for tlb_migrate_finish() to be a true no-op
>> (not a call to a no-op function) when compiling for a platform that
>> doesn't need this hook. Could you look into this?
Jack> For platforms that dont define their own tlb_migrate_finish,
Jack> it is defined as :
Jack> #define tlb_migrate_finish(mm) do {} while (0)
Jack> I'm not sure if I understood your point above. This is
Jack> consistent with other noop definitions (at least some of them)
Jack> & should not generate any code.
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
Then you could do:
# define platform_tlb_migrate_finish machvec_noop(machvec_mm_noop)
I _think_ this should work, provided that callbacks that expand into
true no-ops never have their address taken.
(This reminds me: in the no-op dummy routines in machvec.c should be
named based on the type-signature they use, since it's possible to
share no-op handlers for callbacks with the same type-signature; this
is why I called the no-op machvec_mm_noop in the example above rather
than machvec_tlb_migrate_finish as was the case in your patch).
--david
next prev parent reply other threads:[~2004-07-07 0:01 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 [this message]
2004-07-07 13:52 ` John Richard Moser
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=16619.15708.487344.93894@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--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.