Re: flush_icache_range

["Menyhart, Zoltan" <Zoltan.Menyhart@free.fr>]

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\x111685596128411&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