Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
posted by martyb on Thursday April 24 2014, @06:33PM   Printer-friendly
from the page-processing-patch-provides-performance-plus-power-perks dept.

Mark D. Hill and his peers at the University of Wisconsin-Madison have been analyzing computing systems, trying to look for delays in the architecture and the interfaces between them.

Through careful analysis, Hill uncovers inefficiencies, sometimes major ones, in the workflows by which computers operate. Recently, he investigated inefficiencies in the way that computers implement virtual memory and determined that these operations can waste up to 50 percent of a computer's execution cycles.

The inefficiencies he found were due to the way computers had evolved over time. Memory had grown a million times bigger since the 1980s, but the way it was used had barely changed at all. A legacy method called paging, that was created when memory was far smaller, was preventing processors from achieving their peak potential.

Hill designed a solution(pdf) that uses paging selectively, adopting a simpler address translation method for key parts of important applications. This reduced the problem, bringing cache misses down to less than 1 percent. In the age of the nanosecond, fixing such inefficiencies pays dividends. For instance, with such a fix in place, Facebook could buy far fewer computers to do the same workload, saving millions.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Funny) by bob_super on Thursday April 24 2014, @06:54PM

    by bob_super (1357) on Thursday April 24 2014, @06:54PM (#35722)

    Seriously, who knows how much faster Firefox would display SolylentNews, if that stupid "System Idle Process" wasn't always taking 90% of my CPU time?

    • (Score: 2) by mth on Thursday April 24 2014, @07:02PM

      by mth (2848) on Thursday April 24 2014, @07:02PM (#35726) Homepage

      And it's totally unnecessary: SoylentNews doesn't even have an Idle section.

      • (Score: 2) by davester666 on Friday April 25 2014, @03:54AM

        by davester666 (155) on Friday April 25 2014, @03:54AM (#35922)

        It still needs to poll constantly to check if the section has been created in the last millisecond.

  • (Score: 0) by Anonymous Coward on Thursday April 24 2014, @06:57PM

    by Anonymous Coward on Thursday April 24 2014, @06:57PM (#35723)

    Cache misses in a properly configured system running under normal conditions should never reach 4%. If it is a low IO intensive server the miss rate should always be below 1%.

    This sounds like standard tech journalism from someone that does not even have a freshman understanding of the words he is typing.

    • (Score: 3, Informative) by soylentsandor on Thursday April 24 2014, @08:27PM

      by soylentsandor (309) on Thursday April 24 2014, @08:27PM (#35771)

      This sounds like standard tech journalism from someone that does not even have a freshman understanding of the words he is typing.

      Oh sure, get on your high horses and dismiss it because you know it all.

      To start, the relevant bit in TFA is about virtual memory, not about cache. Furthermore, there was an article about this very issue [slashdot.org] on the green site nearly 4 years ago. TFA that it used to link to discussed the Varnish approach and how it enabled Varnish to perform one or two orders of magnitude better than the competition. Unfortunately, the linked FA now gives a nice Java exception after a fairly long wait. However, I found something similar [varnish-cache.org] on the Varnish site.

      The original FA went a little more in depth than the one on the Varnish site linked above, explaining that back in 1980 or so, when a page fault would occur, it would take a couple orders of magnitude less cpu cycles (though likely more time) to fetch the data from swap than it would today. The result nowadays: even with a low amount of page faults, that means a lot of cpu cycles are wasted (or at least a relatively high amount of time is lost for the affected request) relative to an implementation that manages to encounter less page faults. The same goes for L1, L2 and L3 cache misses. Techniques to minimise both page faults and L[123] cache misses are discussed in the last paragraph of the aforementioned Varnish article [varnish-cache.org].

  • (Score: 4, Insightful) by maxwell demon on Thursday April 24 2014, @07:20PM

    by maxwell demon (1608) on Thursday April 24 2014, @07:20PM (#35732) Journal

    The paper is about GPU memory access. I guess most of Facebook's computing still runs on CPUs, therefore I strongly doubt it would help them much.

    --
    The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 5, Informative) by Angry Jesus on Thursday April 24 2014, @08:33PM

      by Angry Jesus (182) on Thursday April 24 2014, @08:33PM (#35773)

      > The paper is about GPU memory access.

      GPU access to ram shared with the host CPU (rather than private to the GPU).

      FWIW, I expected that using large pages (e.g. 4MB rather than the traditional 4KB) would be very effective in reducing the GPU's TLB miss rate. The paper acknowledges it up front, they say that with their benchmarks they got basically the same improvement by just using 2MB pages. But they think that requiring the app developer to use large pages would be burdensome. Based on my own HPC experience, large pages are very easy to use with little downside. Typically all you have to do is make sure to allocate the memory in a contiguous block that is correctly aligned. It is a few extra lines of code up front and then you can basically forget about it afterwards, it just works. So I'm thinking that while this paper is interesting, it will probably not have much of an impact.

  • (Score: 5, Informative) by takyon on Thursday April 24 2014, @07:59PM

    by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Thursday April 24 2014, @07:59PM (#35756) Journal
    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 3, Insightful) by Ken_g6 on Thursday April 24 2014, @08:25PM

    by Ken_g6 (3706) on Thursday April 24 2014, @08:25PM (#35768)

    And when will a kernel patch be applied to trunk to implement this paging improvement?