Re: flush_icache_range

From: Menyhart, Zoltan <Zoltan.Menyhart_at_free.fr>
Date: 2005-05-30 06:23:23
David Mosberger wrote:

Zoltan> I think we cannot use per-CPU data
 > Why?  I didn't think it was used until per-CPU is initialized.

The point is if we used the per-CPU stride size reported by the PAL
for each CPU, and if we stored these values in their respective per-CPU
data area, then they could be different - on a hypothetic mixed system.
We need a stride size that suits for all the CPUs.

  Zoltan> and there is no need for using per-CPU data, because fc.i a
  Zoltan> global operation, the stride size is a common global value
  Zoltan> for a give machine.
 > Ugh, where that is say that?  I can easily imagine a processor where
 > your argument would not hold true.

fc.i is a global operation as any of the CPUs may have some old
instructions in its i-cache(s).
We need to use the minimum of the stride sizes (that suits for all the
CPUs) - on a hypothetic mixed system.
We use a pre-calculated system wide stride size, then why to
replicate this common value in the per-CPU data areas, why not
to use simply a global variable?

I prefer not to support mixed configurations as there is not such a
real machine, => no need to calculate the min. stride size. This is how
my last patch works.
Even much simpler, the "#ifdef CONFIG_ITANIUM" based solution,
(see my patch on 2005-05-23), would be enough in this case:
http://marc.theaimsgroup.com/?l=linux-ia64&m=111685596128411&w=2

 > BTW: instead of calculating the min log2 stride, I'd just export the
 > actual stride.  No point doing that in flush_cache over and over
 > again.

We use in "flush_icache_range()" the
   loop_counter = ( end_address - start_address - 1 )  / stride_size
equation. It is more efficient to use a shift by log2(stride_size) than
a division.
We also need the stride size to increment the address for fc.i.

Thanks,

Zoltan


-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Sun May 29 16:23:39 2005

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:39 EST