Re: [PATCH 05/10] Invalidate or shrink dcache when setting is changed.

[Yao Qi <yao at codesourcery dot com>]

On 11/19/2013 07:38 PM, Pedro Alves wrote:
> Sure, OK, I guess I did the wrong question then.  I really mean,
> why should we care about preserving the cache when the user
> changes cache size?  What makes this a use case users actually
> care about?  I don't think users going to be doing this

To question #1, because it is expensive to fetch contents from target
memory, and it is unnecessary to flush cache when user changes cache size.

To question #2, nothing.  Cache invalidation is invisible to user.

> sort of thing in a loop?  At most a couple times to check which
> size might be better for then, and then stick it in .gdbinit,
> forever after forgotten.
>
> Actually, if I was probing for the ideal size, I think I'd be
> annoyed that GDB didn't flush the cache, as I'd try
> disassembling/backtracing with different cache sizes, and
> always want to start from a cold cache.

I agree that use case #3 is not very useful.

> > >This "extra complication" looks natural or reasonable to a software
> > >cache.
> It's always a complication/necessity/usefulness balance.
> It doesn't look so reasonable if the complication it adds
> isn't useful in practice, because more code usually means more
> chances of getting things wrong.  The question is then what is
> the real use case that makes this necessary, as opposed to keeping
> it simple.

If use case #1 and #2 are not real use cases, I don't have a real use 
case to show the cache invalidation is avoided due this patch.

--
Yao (éå)