> Now, 5 meg as a cache, isn't that too much?? Some people think this is
Nope, I routinly run with 80MB swap (here and at home.) And it's a
difficult question, because there are tradeoffs: Either you want one bzip
to run fast, or you want a dozen bzip par. run with high troughput.
(That's nicely demonstrated by EIDE/SCSI on a multiuser server: Replacing
a 5 yrs old SCSI disc with a new EIDE that was in benchmarks 3-4 times
faster resulted in grinding teh server to a halt. I had to replace EIDE
disc with a new SCSI disc, which again in benchmarks is about 50-60% of
the speed of the EIDE disc, but I can do background kernel recompiles
without anyone even noticing :) ).
> needed, well I can tell you, it isn't. A year ago, I did some testing on
> a 486DX33 with 8 meg, running DOS/winslows 3.11. I tried different
> cache-sizes (with pc-cache) and measured the speedup while starting up
Comparing the Linux cache subsystem to SMARTDRV is like doing performance
testing on LADA and then applying the findings to BMW/Cadillac/... They
may hald true, but they may hold also not true!
> MS-Word. Maybe you think that's not the way to test this, but why not?
> You test the speed-up in real-life applications, because that's what you
> do all day. So, speedup from 0 to 64 kB cache, 20 seconds, from 64 to 128
> kB cache, 14 seconds, from 128 to 256 kB, 6 seconds, from 256 to 512 kB, 3
> seconds, and from 512 to 1024 kB, 1 second. Now why in gods name would
Again, on a Single-User box a different memory management may seem better.
(But what happens if the single-user becomes a power user and begins to
``multitask'' heavily?)
> one want 5 meg of cache? It will increase the speed of disk-activity with
> maybe 1 second of a 2,5 meg cache. My oppinion is that for 16 meg of
> memory, the minimum-limit for a disk-cache should be 256kB, not 5 meg!!
Nope, that sucks. I know how NeXT with 800kb-2MB cache runs on the same
hardware as Linux. Limiting the cache is not a very clever thing.
>
> Okay, you say, but what about all those idling programs that are stuck in
> memory, and just take up memory from the cache. I know, I know, there are
> cases where it's needed to run such programs, but not always. People are
> running to many idle programs these days! Why do you think there is a
Nope. By definitation a process that does a sleep(3600); should not be a
hurden on the system. -> That's usual POSIX coding understanding.
And not all can be handled by inetd, and not all should be handled.
> inet-daemon? So that there don't need to be a dozen idle processes who
> are checking if there isn't something knocking on there port. Running 6
They are not checking. They are blocked. And that means they are eligible
for swapping.
> or more agetty's? There exists something like a console spawn daemon, you
Nice. And what if each of the ``getty's'' does a different thing? (One
menu for system halt/restart/etc., one menu to restart gpm [Did you notice
it's quite impossible to find GOOD 3 button trackballs today, especially
if you don't want to pay MEGABUCKs? I've got one here, that seems to
``powerdown'' and needs to be restarted with button pressed, ...]
> If I run a bash on a console, and I do something on another console for a
> while, and I return to the first one, I want the bash-process to respond
> immediatly to my key-strokes. I don't like to wait for it until it's
> loaded from swap. My opinion is this: if I run something, it is because
> it needs to run, and it must be able to respond immediatly. If this is
But Linux is Unix and by definition is a server OS. If you want a buggy
scheduler implementation, than go buy OS/2 or NT *g*. (I've seen a nice
SQL server for OS/2, but the scheduler was quite broken: It automatically
decreased the priority of the server if you minimized it. So the Server
had to run in foreground all the time, ...)
> not so, I wont run it. I don't have memory to throw around, I need every
> bit. (And no, memory for a portable is not that cheap)
Than you want to use it more cleverly than to have say 900kb wasted on
bash blocked on read(0,..,..);
> So think about this, when you people change something in the
> memory-management of linux, because it'll run on low-budget and
> high-budget systems...
The point is, that Linux is as a server OS more optimized for the
multitasking/multiuser troughput. And that's the complicated one: If you
want to run one thing a time, than DOS quite cut it :)
> Jan Gyselink
> for the moment a swapping linux-user
Nothing bad about swapping. (And running bzip on a underpowered machine
was always painful. If it wouldn't be so painful, than bzip would have
long replaced gzip, right?)
> PS: i hope .90 is better, 'll try it tonight, but after I rebooted,
> because my console is messed up by Xwindows, who didn't restore the state
> after it finished (maybe caused by to much swapping?????)
Why should swapping influence this? *wonder*
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu