Re: [PATCH] - Reduce TLB flushing during process migration

[Jack Steiner <steiner@sgi.com>]

On Tue, Jul 06, 2004 at 05:01:32PM -0700, David Mosberger wrote:
> >>>>> 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

Your suggestion looks good. I'll code it over the next few days & verify
that it works.

As far as the tlb_migrate patch is concerned, the change to the way machvec
noop functions are implemented is mostly unrelated to the tlb_migrate
patch. We can apply the patches in 2 ways:

	- change machvec noop functions
	- rework the tlb_migrate patch on top of that change

		OR

	- apply the tlb_migrate patch in it's current form
	- change the machvec noop functions including the tlb_migrate noop

Either works. I'm partial to #2 (easier) but will do either....


Note: calling a noop function after an explicit process migration is untidy but 
is not a measurable performance problem. I agree, however, that
the noop function should be improved. At some point in the future, other
noop functions may be added that ARE performance sensitive. It is good to
have the correct infrastructure implemented.


-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.