[lkml]   [2004]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: why swap at all?

    > Gentlemen,

    > There is not enough RAM address-space in even 64-bit machines
    > to do a sort/merge of even a typical inventory with all the
    > keys present in RAM. So you need multiple tasks, each with
    > as much of the 64-bit address-space occupied by RAM, as
    > possible. Even then, you need to do partial sorts, etc.

    Ironically, a fortune 500 company I left very recently is famous for their
    inventory system that has been implemented in the last three years. If
    someone were to assume I am exaggerating, a search for my name in google
    groups would likely reveal what company that is, and looking up news about
    their at would likely churn up a few articles about the
    adda-boys they have received for their inventory system and what it has done
    for the company.

    I was the primary system admin/engineer for this system and it only occupied
    roughly 1TB in a single database instance. 1TB would certainly fit in a
    64-bit address space. While they didn't have a zillion sku's like a company
    like Walmart would, their skus change on a regular basis and change at the
    store level while information about a jar of mayonnaise or a desk in most
    companies can stay quite static. Where I am going with this is I doubt there
    are many inventory systems out there that run much in excess of a few

    > It's not "bloat-ware" that requires getting as much free RAM
    > as possible for an application, but the business of doing business.
    > So, performance of data-intensive work such as the sort/merge
    > is improved by writing the contents of sleeping tasks RAM to
    > a storage device and using that RAM. It's just that simple.

    Again, my expectation is that most large database instances out there will
    happily fit in a 64-bit address space. Ironically, while code tends to run
    slower on 64-bit architectures because of reasons like having half as many
    cache lines because of the larger word size, byte packing, etc.. The ability
    to do a hash join in memory of two insanely large tables that wouldn't fit
    into a 32-bit address space easily negates this small issue. So in that
    regard, a 64-bit address space results in a performance boost provided the
    DBA knows how to leverage the features.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.024 / U:11.268 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site