I actually think the WinModem idea is basically a good one,
even though I'm embarrassed that I was dumb enough to buy one. :-)
The strategy of using the general-purpose CPU for various
tasks makes a lot of sense at the low end. It just makes
it a bitch to write drivers for an "unimportant" platform.
Hopefully Linux's recent surge will help correct that problem.
In general, though, it often does make sense to use the
main CPU for any task it's appropriate for. I could advocate
special-purpose hardware for compressed caching (as some
others do), but I don't think it's necessary. The compression
algorithms can be written in C, and with the right hooks,
compressed VM can just be plugged in and do a fine job.
I actually think that our compression algorithms are well
worth a few thousand transistors that it would take
to compress and uncompress data at memory bus speeds (wow!),
but you don't really need that. It's much easier to change
the software, all other things being equal, and as it turns
out, a software-only implementation on a fast processor is
almost as good as a hardware-supported implementation.
(Basically, increasing the compression speed by 2x only lets
you compress about 7% more of your memory, once you
hit the "sweet spot" of compressing at least 3x faster than
a disk fetch. There are diminishing returns once you've
put half your memory into the compression cache.)
>While your idea is correct, you seem to be forgetting
>the fact that disk transfers can be done in parallel
>with useful CPU operations in other tasks.
I do realize that it's an issue. I just don't believe
it's fatal. For many workloads, a system is either CPU bound
or I/O bound, and you can easily tell which. And as CPU's
get faster and memory gets larger, the tradeoffs get less
tense.
>Having to do (potentially a lot of, since you propose
>losing 30% of useful memory) CPU costly compression
>operations is definately not worth it on my system
>(I/O and memory is in good balance with CPU and CPU is
>usually a main bottleneck).
I have a bit of a feeling that compressed caching is being
criticized on shifting grounds. If RAM is cheap, then
buy a little extra and use compression to double it, so
that you never page. If RAM is expensive, and you're
I/O bound, then you clearly need it. Take your pick.
>I agree it might be nice on those el-cheapo 300 MHz,
>32 MB + EIDE Quantum Bigfoot garbage boxes, but I
>really don't feel like optimizing the system to match
>the insanity the people putting together that system
>must have been in...
[soapbox warning: screed ahead]
I don't know. I have five computers on a network at home,
and 4 of them only have 32 MB of RAM. (The other has LOTS.)
Most of the time, for most things, 32 MB is OK. What
I want is for 32MB to be fine more often, and avoid those
nasty bog-downs when I switch from Netscape to the Gimp,
or whatever. Why should I even bother to crack the case
and upgrade to 64MB or 128MB, if compressed VM would
help me out? Ideally, any given 32 MB machine should be
able to page to its disk, page across my network, and
page to its compressed RAM cache---all at the same time,
in a nearly optimal way, so that I don't have to go out and
buy RAM for all of them, when I'm only using *one* in a piggy
way. This is, after all, the whole idea behind big iron---put your
resources in a pool that acts as a buffer, so that some things
run a little slower sometimes, but rarely two orders of magnitude
slower.
This is a very common situation in the real world. Where
I work, we have networks of perfectly fine machines that
fall apart under heavy load, because they don't help each
other out mainframe-style. Every last one of them has
to be upgraded when the new apps come out and use 2x as
much RAM at peak. We generally throw them out before we
upgrade them twice---it's just not worth it to upgrade
machines twice. It's amazing how expensive it is to
upgrade a computer, when you factor in the cost of staff
to decide when and how to do it. Compressed VM and network
paging could extend the lifetime of existing computers by several
months---from about 18 months to about 24 months. 6 months of
performance cushion is worth a whole heck of a lot of money, in
the big picture. (Think about how much computer price/performance
goes up in 6 months. We're talking billions of dollars a year
here, worldwide.)
The cost-maximization phenomenon of thrashing also acts as a
regressive tax on people who can't afford cutting-edge hardware.
My dad bought one of those 32MB/4GB cheapos recently, and for
very good reason---he's not a computer weenie like me, and
his budget is limited. He doesn't know if this whole computer
thing is worth his time and effort, and he's right to wonder.
These days you can get a 300 MHz processor for about US$100,
and the cost of bunches of RAM really *does* matter at that price
point. People should be able to buy a $500 monitor once every
10 years, and a new $400 computer every two or three years. Computers
shouldn't be expensive like houses and cars, if we can avoid that.
We've got to remember why Linus wrote Linux in the first place---to
have an operating system that could run on a poor student's machine.
It's kind of weird to hear Linux developers saying things to the
effect that paging doesn't matter to them because they have plenty
of RAM, and fast disks. This is a political issue---poor people deserve
a cheap box that works well, if there's no really good reason they
can't have it. Linux should perform as well as is feasible for those boxes,
even if it inevitably performs a lot better for well-off people's boxes.
I don't give away my free software just for well-off dweebs like me.
Rich people can buy plenty of RAM, and poor people can't, or are such
newbies that they don't know how to plug it in. (Does the motherboard
need SDRAM? EDO? My dad just doesn't know.) Insofar as possible, Linux
should be as easy to run acceptably on a bargain-basement machine as it
can be.
There are barriers to entry here that include both economic and
technical problems. Extending the useful life of every bargain-basement
or hand-me-down computer is a great thing to do, politically. Why
should we be lining the pockets of the chip and disk manufacturers? There
are people at Microsoft to do that, who depend on new computer sales
to get revenues from the OS.
Sure, if you really need 128 MB of RAM, you really need it. But most
people don't---even me---and shouldn't have to pay for it.
Even at my price point, these things matter. I have a machine to run
NT (ugh!) for porting, and a machine to run Windows 95 because my
wife needs it for work. I have one linux machine with big RAM, because
I do a few things now and then that require it, and another that's stable,
and a laptop to carry around. But most of the time, I'd like to share
the RAM on the big-RAM machine among the machines I actually use most of the
time. I can't. I'd have to move the SIMMs from one machine to another,
which just isn't worth it for one piggy session, because I've lost the
docs that say what kind of SIMMs I have in which machine, and I've forgotten
how to decipher the BIOS. And for the laptop, I have to buy Toshiba
memory which costs 2 to 3 times what standard SIMMs cost. No way I'm
paying that; I'm comfortable, but I'm not rich. I'll wait another couple
of years until I buy a new, much-cooler laptop that comes with more RAM,
and until then my laptop will thrash if I try to do something nontrivial
on it.
It seems to me that there's a target audience we should be keeping in
mind: Linus before he was *Linus*. Every cash-poor student should be
able to afford a decent machine with a decent LCD screen, which plugs
into a network, and goes with them everywhere they go, so that if they
feel like dinking around on the system, they can. Within 2 years,
every student in a first- or second-world country should be able to
afford a Celeron 500 (clone) computer with a 1024x768 screen, a
bunch of RAM, and maybe no disk, which will plug into a fast ethernet.
That computer should last them 3 years, if at all possible, and maybe
four. The Dynabook is an old idea, but one whose time is about to come,
and cost-saving features like compressed VM are going to have to be
part of it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/