RE: why swap at all?

[Buddy Lumpkin]

> 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 finance.yahoo.com 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
Terabytes.


> 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.

--Buddy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/