linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: kanoj@google.engr.sgi.com
Cc: linux-mm@kvack.org, linux-kernel@vger.rutgers.edu, ralf@uni-koblenz.de
Subject: Re: Questions on cache flushing in do_wp_page
Date: Mon, 7 Jun 1999 14:54:16 -0700	[thread overview]
Message-ID: <199906072154.OAA07427@pizda.davem.net> (raw)
In-Reply-To: <199906072045.NAA71235@google.engr.sgi.com> (kanoj@google.engr.sgi.com)

   > As per virtual cache aliasing issues we handle them in other ways,
   > and it is done on a port-by-port basis since most machines need not
   > handle this brain damage.

   I am assuming then that in the above, your definition of "non-coherent"
   does not include virtual coherency/aliasing issues, since the above
   paragraph seems to imply that those issues are handled differently.

Yes, and I will say it again, broken caches like this are handled
by update_mmu_cache(), nowhere else.

It writes data back into the coherency space if necessary, that is all
these two things do, nothing more.  They do not remap pages, they do
not resolve alias conflicts, they are not meant to.

flush_cache_page(vma, page) is meant to also take care of the case
where for some reason the TLB entry must exist for the cache entry to
be valid as well.  This is the case on the HyperSparc's combined I/D
L2 cache (it has no L1 cache), you cannot flush out cache entries
which have no translation, it will make the cpu trap.  Sparc/sun4c's
mmu is like this too.

   Applying the above formalisms to the MIPS processor in do_wp_page,
   I still can't see why a cache wbinv would be done by the
   flush_page_to_ram(old_page); And if I can not use the argument of
   cache aliasing, I am at a complete loss to explain either of
   flush_page_to_ram(new_page); and flush_cache_page(vma, address);
   doing cache wbinv on the MIPS.

Point to note, the MIPS code in the kernel tree is ages out of date
and is by no means a good reference.  The Sparc code is up to date so
you can check what we do there, the 32-bit port has to deal with all
of these issues in various cache/mmu combinations.  Happily sparc64 is
several orders of magnitude easier and nops most of it out.

   You do mention in the general case where the primitives need to be
   invoked, except I still don't understand which processors can define
   the primitives as no-ops (Intel) and which should do some real work
   (like the MIPS seems to be doing). Is there some way to figure out
   how a given processor/architecture needs to define these routines?

The kernel implicitly aliases with userspace on "alias problematic"
caches, this is why flush_page_to_ram() is a seperate primitive.

View it this way, if physical page X is mapped in userspace at address
Y, and you write bytes into the page in the kernel at the kernel
mapping, and the user will not immediately see this data if he were to
just then read it at Y, you need flush_page_to_ram() to do something.

Later,
David S. Miller
davem@redhat.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

      reply	other threads:[~1999-06-07 21:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-07 19:26 Kanoj Sarcar
1999-06-07 19:44 ` David S. Miller
1999-06-07 20:45   ` Kanoj Sarcar
1999-06-07 21:54     ` David S. Miller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199906072154.OAA07427@pizda.davem.net \
    --to=davem@redhat.com \
    --cc=kanoj@google.engr.sgi.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=ralf@uni-koblenz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox