Re: [linuxsh-dev] Drop-In tree updates

[Jeremy S. <js...@mv...>]

NIIBE Yutaka wrote:

> VIPT: Virtually Indexed Phisically Tagged cache.
>
> For break_cow, we don't need to flush the cache.  On some architecture
> where permission informatipn is there, we need to flush it because it
> was read-only before.  But it's not the case for SuperH.  If you want,
> please try to enable the flushing and see how the performance going
> down.
>
> For the case of do_wp_page, I think conditions still are applied.  The
> logic is same as break_cow.  On some architecture (not SuperH), it is
> needed, or else, the fault occurs again and again.

Thanks -- since I don't know enough about the memory management the
change from exclusive_swap_page() and delete_from_swap_cache() to
can_share_swap_page() made me wonder, but if you say it's still safe, I'm
quite happy to remove it as per your patch!

Robert Love wrote:

> For multiple reasons, shouldn't we do this:
>
> +#if !defined(CONFIG_SUPERH) /* this is not needed for VIPT cache */
>                         flush_cache_page(vma, address);
> +#endif

We'd do it that way in anything we distribute from mvista, of course, but
in the community tree I'd want to defer to the community.  However...

NIIBE Yutaka wrote:

> David Woodhouse wrote:
>  > 2.5 has opened. I think it's time to provide an API to the cache code that
>  > actually makes sense, and the functions bear some relation to their
>  > behaviour and the reasons for calling them.
>
> Yes, that is my point too.  Leave ugly thing as is so that people want
> to do better one.

...I think that to encourage a general API rewrite the ugliness has to be in
the kernel.org tree; if it's only in the linuxsh tree only we will care.  If
I had
to compare #if 0 and #ifndef CONFIG_SUPERH I'd guess the latter would
be more likely to be accepted.  (I know it's generally frowned upon anyway,
but it might get someone thinking; the #if 0 submission would probably be
banned outright.)

Another minor point: even in the linuxsh tree itself, using CONFIG helps
make it clear that this is deliberate, and not leftover/experimental hackery.
(Maybe that's one of the other "multiple reasons" Robert refers to;-)

--Jeremy Siegel