L1,L2 caches and MMU - Linux

This is a discussion on L1,L2 caches and MMU - Linux ; Hi, Does L1 "memory cache" cache virtual addresses or physical addresses? I.E is L1 cache located after the memory management unit (MMU) and the TLB or before? What about L2 cache? which relative location gives better performances? I am more ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 30

Thread: L1,L2 caches and MMU

  1. L1,L2 caches and MMU

    Hi,

    Does L1 "memory cache" cache virtual addresses or physical addresses?
    I.E is L1 cache located after the memory management unit (MMU) and the
    TLB or before? What about L2 cache? which relative location gives
    better performances? I am more interested on intel x86 processors.

    Another question regarding the TLB content on a context switch. Does
    the system stores its entire content in memory and then loaded it back
    once the process is re-activated? Or instead it simply invalidates its
    content so the process addresses miss always on a TLB once it is
    restarted

    my understanding is that flushing a TLB by invalidating its entries is
    equivalent to resetting the TLB entries to zero including the TLB entry
    valid bit. I don't expect that this operation can be done
    asynchronously through a dedicated TLB valid reset wire. Is that right
    ?


    Many thanks


  2. Re: L1,L2 caches and MMU

    xu_feng_xu@yahoo.com schrieb:

    > Hi,
    > Does L1 "memory cache" cache virtual addresses or physical addresses?


    Usually physiscal, but there are virtually indexed caches.

    > ... What about L2 cache?


    Also usually physically adressed.

    > ... which relative location gives better performances?


    It's not only a matter of performance. With pure virtually indexed
    caches you'd have to flush the cache on every context-switch and
    you would get into difficulties when snooping a cache from another
    CPU or DMAing I/O-Device.

    > I am more interested on intel x86 processors.


    All x86-CPUs use physically indexed caches (ok, dunno for the
    Transmeta-CPUs, but I think they're also physically indexed).

    > Another question regarding the TLB content on a context switch.
    > Does the system stores its entire content in memory and then
    > loaded it back once the process is re-activated? Or instead
    > it simply invalidates its content so the process addresses
    > miss always on a TLB once it is restarted


    Exactly that, but there might be a trick:
    TLBs that are connected to the page-table-pointer, i.e. the TLBs don't
    need to be flushed because there's not a comparison against the address
    -part but also to the pt-pointer for a specific pte-cache. Does anyone
    know whether this is implemented with any current CPU, any x86-CPU or
    if this is what is called the tlb-flush-filters implemented with some
    x86-CPUs?

    > my understanding is that flushing a TLB by invalidating its entries
    > is equivalent to resetting the TLB entries to zero including the TLB
    > entry valid bit. I don't expect that this operation can be done
    > asynchronously through a dedicated TLB valid reset wire. Is that
    > right?


    Your questions suggest you're a good IT-men.

  3. Re: L1,L2 caches and MMU

    > Exactly that, but there might be a trick:
    > TLBs that are connected to the page-table-pointer, i.e. the TLBs don't
    > need to be flushed because there's not a comparison against the address
    > -part but also to the pt-pointer for a specific pte-cache. Does anyone
    > know whether this is implemented with any current CPU, any x86-CPU or
    > if this is what is called the tlb-flush-filters implemented with some
    > x86-CPUs?


    I just googled for "flush-filter" and found what's meant by that word:
    For x86-CPUs it has to be assured that while a page-table of another
    process isn't in the current CR3-register, writes to the physical pages
    of that page-table have to have an effect when the page-table becomes
    effective when the process-context ist switched to that page-table. So
    he simple approach to hold multiple processes/page-tables PTEs in a sin-
    gle PTE-set/TLB isn't easy to accomplish. The trick is the following:
    When a PTE is loaded, the physical adress from where this PTE is loaded
    is recorded. When we're in a different process-context and we're acces-
    sing PTEs of another process-context, these writes are verified asyn-
    chronously with the flush-filter entries. If we're writing to one of
    the addresses tracked by the flush-filter, a flag for that flush-filter
    is set indicating that the specific PTE needs to be flushed when the
    TLBs are flushed the next time. Nice idea!

  4. Re: L1,L2 caches and MMU


    Elcaro Nosille wrote:
    > xu_feng_xu@yahoo.com schrieb:
    > Your questions suggest you're a good IT-men.


    Or a student with homework due shortly...

    DK


  5. Re: L1,L2 caches and MMU

    David Kanter schrieb:
    > Elcaro Nosille wrote:


    >> xu_feng_xu@yahoo.com schrieb:
    >> Your questions suggest you're a good IT-man.


    > Or a student with homework due shortly...


    I haven't thought he's in practice with his ideas. But the questions
    seem very elaborate so that I think he will be a got It-man as soon
    as he is in practice.

  6. Re: L1,L2 caches and MMU

    In article <454e9f70$0$30317$9b4e6d93@newsspool1.arcor-online.net>,
    Elcaro Nosille wrote:
    > David Kanter schrieb:
    >> Elcaro Nosille wrote:

    >
    >>> xu_feng_xu@yahoo.com schrieb:
    >>> Your questions suggest you're a good IT-man.

    >
    >> Or a student with homework due shortly...

    >
    >I haven't thought he's in practice with his ideas. But the questions
    >seem very elaborate so that I think he will be a got It-man as soon
    >as he is in practice.


    Well. Whatever a "got It-man" is, let me only hope that none such is
    ever anywhere near me.

    --
    Thor Lancelot Simon tls@rek.tjls.com

    "We cannot usually in social life pursue a single value or a single moral
    aim, untroubled by the need to compromise with others." - H.L.A. Hart

  7. Re: L1,L2 caches and MMU

    wrote ...
    > Hi,
    >
    > Does L1 "memory cache" cache virtual addresses or physical addresses?


    Yes, although on some architectures, no.

    > I.E is L1 cache located after the memory management unit (MMU)
    > and the TLB or before?


    Either.

    > What about L2 cache? which relative location gives
    > better performances? I am more interested on intel x86 processors.


    It depends on many things.

    > Another question regarding the TLB content on a context switch. Does
    > the system stores its entire content in memory and then loaded it back
    > once the process is re-activated? Or instead it simply invalidates its
    > content so the process addresses miss always on a TLB once it is
    > restarted


    It depends.

    > my understanding is that flushing a TLB by invalidating its entries is
    > equivalent to resetting the TLB entries to zero including the TLB entry
    > valid bit. I don't expect that this operation can be done asynchronously
    > through a dedicated TLB valid reset wire. Is that right ?


    No.

    You'd learn more figuring these things out for yourself.
    That's what homework is for.
    --
    Dennis M. O'Connor dmoc@primenet.com



  8. Re: L1,L2 caches and MMU

    >> I haven't thought he's in practice with his ideas. But the questions
    >> seem very elaborate so that I think he will be a got It-man as soon
    >> as he is in practice.


    > Well. Whatever a "got It-man" is, let me only hope that none such is
    > ever anywhere near me.


    Why?

  9. Re: L1,L2 caches and MMU

    That's one of the typical posting where someone is asking questions
    for himself but not for the questioner. Except from the first question
    there's really nothing substantial; and even the first one wouldn't
    be satisfactory for the questioner.
    The only reason for posting like yours is: show that you would be able
    to answer the questions to suggest that you're competent; or even not
    if you wouldn't be able to answer the questions if you're a show-off
    that likes other to believe that he's competent.
    I'm really annoyed about such uttelry stupid postings.

    Dennis M. O'Connor schrieb:

    > wrote ...
    >> Hi,
    >> Does L1 "memory cache" cache virtual addresses or physical addresses?

    >
    > Yes, although on some architectures, no.
    >
    >> I.E is L1 cache located after the memory management unit (MMU)
    >> and the TLB or before?

    >
    > Either.
    >
    >> What about L2 cache? which relative location gives
    >> better performances? I am more interested on intel x86 processors.

    >
    > It depends on many things.
    >
    >> Another question regarding the TLB content on a context switch. Does
    >> the system stores its entire content in memory and then loaded it back
    >> once the process is re-activated? Or instead it simply invalidates its
    >> content so the process addresses miss always on a TLB once it is
    >> restarted

    >
    > It depends.
    >
    >> my understanding is that flushing a TLB by invalidating its entries is
    >> equivalent to resetting the TLB entries to zero including the TLB entry
    >> valid bit. I don't expect that this operation can be done asynchronously
    >> through a dedicated TLB valid reset wire. Is that right ?

    >
    > No.
    >
    > You'd learn more figuring these things out for yourself.
    > That's what homework is for.
    > --
    > Dennis M. O'Connor dmoc@primenet.com
    >
    >


  10. Re: L1,L2 caches and MMU

    "Dennis M. O'Connor" writes:

    > wrote ...
    > > Hi,
    > >
    > > Does L1 "memory cache" cache virtual addresses or physical addresses?

    >
    > Yes, although on some architectures, no.


    Hmmm? I must be missing something. I can't think of an architecture
    where the answer is "no". Or are you thinking of the P4 trace cache?

    Other than that, I think your response was the clearest and most
    concise description of the relationship between TLB, MMU, and cache
    I've ever seen.
    --
    Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
    Department of Computer Science FAX -- (505) 646-1002
    New Mexico State University http://www.cs.nmsu.edu/~pfeiffer

  11. Re: L1,L2 caches and MMU


    In article <1162783472.911092@nnrp2.phx1.gblx.net>,
    "Dennis M. O'Connor" writes:
    |>
    |> You'd learn more figuring these things out for yourself.
    |> That's what homework is for.

    I think that is what he is trying to do - only some of the issues he
    raised are described in the public documentation (i.e. the architecture
    manuals). Others are in the implementation (i.e. CPU model) dependent
    documentation or in the operating system sources, which are not usually
    easy to get hold of.


    Regards,
    Nick Maclaren.

  12. Re: L1,L2 caches and MMU


    In article <1b8xip5gvc.fsf@viper.cs.nmsu.edu>,
    Joe Pfeiffer writes:
    |> "Dennis M. O'Connor" writes:
    |> > wrote ...
    |> > > Hi,
    |> > >
    |> > > Does L1 "memory cache" cache virtual addresses or physical addresses?
    |> >
    |> > Yes, although on some architectures, no.
    |>
    |> Hmmm? I must be missing something. I can't think of an architecture
    |> where the answer is "no". Or are you thinking of the P4 trace cache?

    I can :-)

    The answer is associative memory ....


    Regards,
    Nick Maclaren.

  13. Re: L1,L2 caches and MMU


    Nick Maclaren wrote:
    > In article <1162783472.911092@nnrp2.phx1.gblx.net>,
    > "Dennis M. O'Connor" writes:
    > |>
    > |> You'd learn more figuring these things out for yourself.
    > |> That's what homework is for.


    > I think that is what he is trying to do - only some of the issues he
    > raised are described in the public documentation (i.e. the architecture
    > manuals). Others are in the implementation (i.e. CPU model) dependent
    > documentation or in the operating system sources, which are not usually
    > easy to get hold of.


    Actually it's rather easy to find that information for any recent x86
    processors. Just look in the tuning manuals for Intel and AMD (I don't
    know about VIA). IBM also has quite a bit of information about the
    POWER4/5 memory systems.

    There are also quite a few articles on different architectures which
    detail much of this information..

    DK


  14. Re: L1,L2 caches and MMU


    In article <1162808532.890104.301340@h48g2000cwc.googlegroups. com>,
    "David Kanter" writes:
    |>
    |> > I think that is what he is trying to do - only some of the issues he
    |> > raised are described in the public documentation (i.e. the architecture
    |> > manuals). Others are in the implementation (i.e. CPU model) dependent
    |> > documentation or in the operating system sources, which are not usually
    |> > easy to get hold of.
    |>
    |> Actually it's rather easy to find that information for any recent x86
    |> processors. Just look in the tuning manuals for Intel and AMD (I don't
    |> know about VIA). IBM also has quite a bit of information about the
    |> POWER4/5 memory systems.

    Well, considering that a fair number of the issues are dependent on how
    the operating system has chosen to use the hardware facilities, there
    is a question of how reliable that information is ....

    In that, I am referring to the TLB questions, of course.

    There is also the problem that tuning manuals very often get out of date
    when referring to information that is functionally transparent and likely
    to vary with CPU model. Even when the manual is being actively updated,
    it is rare for it to be changed just because a new model does something
    different if the actual tuning advice doesn't change.

    |> There are also quite a few articles on different architectures which
    |> detail much of this information..

    Some of which are right, some misleading and some plain wrong. Until
    you know the answer, it is hard to tell which. Vendor articles will
    rarely be the last, but arbitrary Web ones may be.


    Regards,
    Nick Maclaren.

  15. Re: L1,L2 caches and MMU


    Nick Maclaren wrote:
    > In article <1162808532.890104.301340@h48g2000cwc.googlegroups. com>,
    > "David Kanter" writes:
    > |>
    > |> > I think that is what he is trying to do - only some of the issues he
    > |> > raised are described in the public documentation (i.e. the architecture
    > |> > manuals). Others are in the implementation (i.e. CPU model) dependent
    > |> > documentation or in the operating system sources, which are not usually
    > |> > easy to get hold of.
    > |>
    > |> Actually it's rather easy to find that information for any recent x86
    > |> processors. Just look in the tuning manuals for Intel and AMD (I don't
    > |> know about VIA). IBM also has quite a bit of information about the
    > |> POWER4/5 memory systems.
    >
    > Well, considering that a fair number of the issues are dependent on how
    > the operating system has chosen to use the hardware facilities, there
    > is a question of how reliable that information is ....
    >
    > In that, I am referring to the TLB questions, of course.
    >
    > There is also the problem that tuning manuals very often get out of date
    > when referring to information that is functionally transparent and likely
    > to vary with CPU model. Even when the manual is being actively updated,
    > it is rare for it to be changed just because a new model does something
    > different if the actual tuning advice doesn't change.
    >
    > |> There are also quite a few articles on different architectures which
    > |> detail much of this information..
    >
    > Some of which are right, some misleading and some plain wrong. Until
    > you know the answer, it is hard to tell which. Vendor articles will
    > rarely be the last, but arbitrary Web ones may be.
    >
    >
    > Regards,
    > Nick Maclaren.


    Many thanks to you Elcaro Nosille for your reply.

    Nick, you summarise the situation very well. i can give two links one
    stating that L1 cache cache virtual addresses and the other stating
    the opposite thing. I can't find a single OS textbook that details the
    implementation side and i have looked extensively in the library. A
    friend of mine asks me to focus on one particular OS and a single
    processor first and i think he might be right...


  16. Re: L1,L2 caches and MMU


    In article <1162817805.341288.30030@i42g2000cwa.googlegroups.c om>,
    xu_feng_xu@yahoo.com writes:
    |>
    |> Nick, you summarise the situation very well. i can give two links one
    |> stating that L1 cache cache virtual addresses and the other stating
    |> the opposite thing. I can't find a single OS textbook that details the
    |> implementation side and i have looked extensively in the library. A
    |> friend of mine asks me to focus on one particular OS and a single
    |> processor first and i think he might be right...

    Start with the cache, and ignore the operating system aspects, which
    are rarely relevant. Probably start with x86 and then look at a few
    other architectures.

    The TLB questions are MUCH harder to track down as they refer to the
    poorly documented border between the hardware and operating system.
    I gave up trying to follow what systems did a couple of decades back,
    due to lack of precise descriptions (and irrelevance).


    Regards,
    Nick Maclaren.

  17. Re: L1,L2 caches and MMU


    "Joe Pfeiffer" wrote in message
    news:1b8xip5gvc.fsf@viper.cs.nmsu.edu...
    > "Dennis M. O'Connor" writes:
    >
    >> wrote ...
    >> > Hi,
    >> >
    >> > Does L1 "memory cache" cache virtual addresses or physical addresses?

    >>
    >> Yes, although on some architectures, no.

    >
    > Hmmm? I must be missing something. I can't think of an architecture
    > where the answer is "no". Or are you thinking of the P4 trace cache?


    I as thinking of architectures that have a third address
    space, in addition to virtual and physical, like ARM's
    Modified Virtual Addresses.

    > Other than that, I think your response was the clearest and most
    > concise description of the relationship between TLB, MMU, and cache
    > I've ever seen.


    Thanks !
    --
    Dennis M. O'Connor dmoc@primenet.com



  18. Re: L1,L2 caches and MMU

    nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

    > In article <1b8xip5gvc.fsf@viper.cs.nmsu.edu>,
    > Joe Pfeiffer writes:
    > |> "Dennis M. O'Connor" writes:
    > |> > wrote ...
    > |> > > Hi,
    > |> > >
    > |> > > Does L1 "memory cache" cache virtual addresses or physical addresses?
    > |> >
    > |> > Yes, although on some architectures, no.
    > |>
    > |> Hmmm? I must be missing something. I can't think of an architecture
    > |> where the answer is "no". Or are you thinking of the P4 trace cache?
    >
    > I can :-)
    >
    > The answer is associative memory ....


    Associative main memory is sort of outside the mainline at this point...

    --
    Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
    Department of Computer Science FAX -- (505) 646-1002
    New Mexico State University http://www.cs.nmsu.edu/~pfeiffer

  19. Re: L1,L2 caches and MMU


    In article <1bac347hx5.fsf@viper.cs.nmsu.edu>,
    Joe Pfeiffer writes:
    |>
    |> Associative main memory is sort of outside the mainline at this point...

    It has existed, and there are reasons to believe that it should be
    'rediscovered', but I don't expect to see it back again. I don't
    see that it would help with the 'memory wall' without changes in
    programming paradigms, either. But you have to admit that it does
    meet the criterion of being neither real nor virtual memory :-)


    Regards,
    Nick Maclaren.

  20. Re: L1,L2 caches and MMU

    Elcaro Nosille wrote:

    > All x86-CPUs use physically indexed caches (ok, dunno for the
    > Transmeta-CPUs, but I think they're also physically indexed).


    IIRC, Athlons use three bits of virtual-only addressing. To handle
    aliases it must snoop 16 entries (8 indices, and two ways) on a
    L1 cache miss and invalidate an aliased entry if it exists.


    Paul A. Clayton
    just a technophile


+ Reply to Thread
Page 1 of 2 1 2 LastLast