Cache, TLB and OS - Linux

This is a discussion on Cache, TLB and OS - Linux ; Hi, I am confused about the following point regarding Virtual Indexed Tag Indexed Cache and i woul appreciate any help I have read in this article http://www.linuxjournal.com/article/7105 , the following: several other problems: 1- Virtual address translations usually are changed ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Cache, TLB and OS

  1. Cache, TLB and OS

    Hi,


    I am confused about the following point regarding Virtual Indexed Tag
    Indexed Cache and i woul appreciate any help

    I have read in this article http://www.linuxjournal.com/article/7105 ,
    the following:

    << In virtually indexed, virtually tagged (VIVT) caches...suffer from
    several other problems:

    1- Virtual address translations usually are changed as part of normal
    kernel operation, so the cache must pay careful attention to changes in
    TLB entries (and changes in address space) and flush cache lines whose
    translations have changed.

    2- Even in a single address space, multiple virtual addresses may exist
    for the same physical address. Each of these virtual addresses would be
    cached separately, even though they represent the same data. This is
    called the cache-line aliasing problem.
    >>


    I am just confused about the author:

    1- first point, why the cache has to be bothered by the change in the
    address logical-physical mapping since it is a virtual cache??
    2- could you please give me a situation where two virtual addresses
    from the same process are mapped to the same physical address? i can't
    see this happening since each process page is allocated a dedicated
    frame.


    sorry if my questions seem obvious

    thank you for your help


  2. Re: Cache, TLB and OS

    wrote in message
    news:1165715832.332827.222760@73g2000cwn.googlegro ups.com...
    > 2- could you please give me a situation where two virtual addresses
    > from the same process are mapped to the same physical address?


    Process forks with copy-on-write.
    --
    Dennis M. O'Connor



  3. Re: Cache, TLB and OS

    xu_feng_xu@yahoo.com writes:

    >I am just confused about the author:


    You are confused about the fundamentals.

    I'll try to make it easy for you.

    Physical memory and physical adresses are unique on the whole running system.

    Virtual memory and virtual addresses are private to each process, and nonunique
    between different processes.

    (replace process with whatever word the OS you are interested in uses
    for the entity which "has" a separate page table tree which is switched
    during context switches)

    >1- first point, why the cache has to be bothered by the change in the
    >address logical-physical mapping since it is a virtual cache??


    What would happen otherwise? Here's a simple example:

    When my newsreader process read your article from disk, the text you
    wrote came to virtual address 0x12345420, and was cached under that index.
    Then, before my newsreader process could start to display the text
    on my screen, the operating system scheduled a different process
    to run on the CPU, say my email reception program. As it happened,
    that process just received an email, with the email text coming
    to sit at virtual address 0x12345420. As the OS did not care about
    cache flushing during schedule, part of the email text overwrites
    what the newsreader process put in that cache line a millisecond ago.
    When the newsreader is finally rescheduled, and displays your posting,
    I get to see the text of that email message, instead of your questions.

    >2- could you please give me a situation where two virtual addresses
    >from the same process are mapped to the same physical address? i can't
    >see this happening since each process page is allocated a dedicated
    >frame.


    There is anonymous memory, private to each process, which is probably
    all you were thinking about. And there is file backed memory. For the
    file backed memory, OSses tend to keep a single physical copy of
    all recently read blocks in physical memory, called a file cache
    or page cache or something like that. When processes access files
    through the usual memory mapping (mmap) interfaces, the process
    page tables will directly reference those cache pages, so no copying
    of the file contents is involved. When a process, for whatever reason,
    mmaps the same file twice, it will have two different virtual addresses
    referring to the same pysical address.

    best regards
    Patrick

  4. Re: Cache, TLB and OS

    "Dennis M. O'Connor" writes:
    > wrote in message
    >news:1165715832.332827.222760@73g2000cwn.googlegro ups.com...
    >> 2- could you please give me a situation where two virtual addresses
    >> from the same process are mapped to the same physical address?


    http://www.complang.tuwien.ac.at/ant...16k/mapcheck.c

    Also, anonymously mapped memory may share the same physical page for
    all virtual pages that have not been written yet.

    >Process forks with copy-on-write.


    Different processes, same virtual address.

    Followups set to comp.arch.

    - anton
    --
    M. Anton Ertl Some things have to be seen to be believed
    anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
    http://www.complang.tuwien.ac.at/anton/home.html

  5. Re: Cache, TLB and OS


    Patrick Schaaf wrote:
    > xu_feng_xu@yahoo.com writes:
    >
    > >I am just confused about the author:

    >
    > You are confused about the fundamentals.
    >
    > I'll try to make it easy for you.
    >
    > Physical memory and physical adresses are unique on the whole running system.
    >
    > Virtual memory and virtual addresses are private to each process, and nonunique
    > between different processes.
    >
    > (replace process with whatever word the OS you are interested in uses
    > for the entity which "has" a separate page table tree which is switched
    > during context switches)
    >
    > >1- first point, why the cache has to be bothered by the change in the
    > >address logical-physical mapping since it is a virtual cache??

    >
    > What would happen otherwise? Here's a simple example:
    >
    > When my newsreader process read your article from disk, the text you
    > wrote came to virtual address 0x12345420, and was cached under that index.
    > Then, before my newsreader process could start to display the text
    > on my screen, the operating system scheduled a different process
    > to run on the CPU, say my email reception program. As it happened,
    > that process just received an email, with the email text coming
    > to sit at virtual address 0x12345420. As the OS did not care about
    > cache flushing during schedule, part of the email text overwrites
    > what the newsreader process put in that cache line a millisecond ago.
    > When the newsreader is finally rescheduled, and displays your posting,
    > I get to see the text of that email message, instead of your questions.



    Thanks Patrick. I should have mentionned a single address space. I
    understand that in multiprogramming this is a problem which can be
    solved by flushing the cache or checking the PID since the latter is
    unique for each process


  6. Re: Cache, TLB and OS


    Anton Ertl wrote:
    > "Dennis M. O'Connor" writes:
    > > wrote in message
    > >news:1165715832.332827.222760@73g2000cwn.googlegro ups.com...
    > >> 2- could you please give me a situation where two virtual addresses
    > >> from the same process are mapped to the same physical address?

    >
    > http://www.complang.tuwien.ac.at/ant...16k/mapcheck.c
    >
    > Also, anonymously mapped memory may share the same physical page for
    > all virtual pages that have not been written yet.



    Thanks Anton. Forgive my ignorance but i dont understand what you do
    mean by :
    "anonymously mapped memory may share the same physical page for
    all virtual pages that have not been written yet."

    Many thanks


  7. Re: Cache, TLB and OS

    "Dennis M. O'Connor" writes:

    > wrote in message
    >news:1165715832.332827.222760@73g2000cwn.googlegro ups.com...
    >> 2- could you please give me a situation where two virtual addresses
    >> from the same process are mapped to the same physical address?


    >Process forks with copy-on-write.


    Multiple copies of the same program (programs are mapped at the
    same location in memory; the text segment is shared)

    Multiple copies of the same shared libraries (which may or may not end
    up on the same virtual address; but typically are mapped at or about
    the same address)

    Shared memory segments

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  8. Re: Cache, TLB and OS

    Casper H.S. Dik writes:
    > Multiple copies of the same program (programs are mapped at the
    > same location in memory; the text segment is shared)
    >
    > Multiple copies of the same shared libraries (which may or may not end
    > up on the same virtual address; but typically are mapped at or about
    > the same address)
    >
    > Shared memory segments


    lots of past posts about dealing with shared memory segments
    potentially mapped at different virtual addresses in different
    virtual address spaces
    http://www.garlic.com/~lynn/subtopic.html#adcon

    an issue is if the TLB (and virtual cache) are virtual address space
    associative ("STO-associative" in some of the discussions) ... then
    they have different TLB/cache entries (even if they might have the
    same physical address and potentially even the same virtual address).
    For shared memory segments ... the problem can go away ... if the
    TLB/cache are segment associative ("PTO-associative" in some of the
    discussions). For instance, you find TLB being virtual segment
    associative (instead of virtual address space associative) in various
    801 machines.

    some postings about 3090 having cache that was indexed by both real
    address (real address associative) and "logical" address (and being
    virtual address space associative).
    http://www.garlic.com/~lynn/2003j.html#42 Flash 10208
    http://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
    http://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch
    http://www.garlic.com/~lynn/2006v.html#43 The Future of CPUs: What's After Multi-Core?

  9. Re: Cache, TLB and OS

    xu_feng_xu@yahoo.com writes:
    >Thanks Anton. Forgive my ignorance but i dont understand what you do
    >mean by :
    >"anonymously mapped memory may share the same physical page for
    > all virtual pages that have not been written yet."


    Anonymously mmapped memory is originally zeroed. How is that
    implemented? One way is: there is one page that is zeroed, and all
    the page table entries for the pages in the virtual memory area point
    to that page (and mark it as read-only, so it can be copied-on-write).

    Followup-To: comp.arch

    - anton
    --
    M. Anton Ertl Some things have to be seen to be believed
    anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
    http://www.complang.tuwien.ac.at/anton/home.html

  10. Re: Cache, TLB and OS

    Anne & Lynn Wheeler writes:
    > lots of past posts about dealing with shared memory segments
    > potentially mapped at different virtual addresses in different
    > virtual address spaces
    > http://www.garlic.com/~lynn/subtopic.html#adcon


    couple recent posts with emails from the early/mid 70s about
    doing shared segment work including support for same virtual
    shared segment appearing at different virtual addresses in different
    virtual address spaces
    http://www.garlic.com/~lynn/2006v.html#36 Why these original Fortran quirks?
    http://www.garlic.com/~lynn/2006w.html#7 Why these original Fortran quirks?
    http://www.garlic.com/~lynn/2006w.html#8 Why these original Fortran quirks?

+ Reply to Thread