Slashdot Mirror
The New Linux Speed Trick
Brainsur quotes a story saying "
Linux kernel 2.6 introduces improved IO scheduling that can increase speed -- "sometimes by 1,000 percent or more, [more] often by 2x" -- for standard desktop workloads, and by as much as 15 percent on many database workloads, according to Andrew Morton of Open Source Development Labs. This increased speed is accomplished by minimizing the disk head movement during concurrent reads.
"
I'm having trouble getting ACPI working in my laptop in the 2.6 kernel (it's a bad implementation on the part of my laptop). The 2.4 series used to work (sometimes) so I installed Mandrake's 2.4 kernel and 2.6 kernels on my laptop. Using 2.4.x again was like switching to a horse and buggy from a sport-cars; KDE was that much faster with the 2.6.x kernel running the show.
Whatever happened to cache. If you can anticipate the head movement surely you have already read the data before and it should be in the cache????
Dont SCSI drives do this themselves?
It seems that the server isn't running the speed improvment becuase its probably slashdotted.
The system was unable to communicate with the server.
A 1000 % increase isn't a multiplication by 1000, you lousy troll...
Linux Devices has an article on the 2.6 network features here http://linuxdevices.com/articles/AT7885999771.html
Open Source PVR Hardware Database
It seems there are two IO modes you can choose from, at boot time.
"The anticipatory scheduling is so named because it anticipates processes doing several dependent reads. In theory, this should minimize the disk head movement. Without anticipation, the heads may have to seek back and forth under several loads, and there is a small delay before the head returns for a seek to see if the process requests another read. "
"The deadline scheduler has two additional scheduling queues that were not available to the 2.4 IO scheduler. The two new queues are a FIFO read queue and a FIFO write queue. This new multi-queue method allows for greater interactivity by giving the read requests a better deadline than write requests, thus ensuring that applications rarely will be delayed by read requests."
Nice, but this is making things more complex. I admit I'll just keep all kernel settings at wherever Mandrake sets them as. Will other people play about and specialise their system for the task that it does?
- Jax
I remember when this feature was added to NT Service Pack 4. Performance on the enterprise database server I was managing increased something like 45%.
It's nice to see smart features like this added to Linux.
Is there any reason why the prediction code (anticipatory scheduler) and the extra queues (deadline scheduler) couldn't be combined in a single scheduler to give us the best of both worlds?
The Tao of math: The numbers you can count are not the real numbers.
Well, nowhere. It says percent not times. So that would be 10x...
When I had an Amiga (aroung '91ish), even though It was fully multitasking, I learnt to never open any app while another was loading. If you did, you could hear the disk head moving back and forward between two sectors on disk every half second or so, slowing both app launches to a crawl. Waiting until one loaded, and launching the second was many times faster.
I've always wondered why there wasn't something in the OS to force this behaviour, Ie, making sure that App 2 access to the disk is queued until app 1 has finished. Isn't this one of the reasons Windows takes ages to boot? (many processes all competing for the one disk resource?).
I've actually found that on my machine, a pretty much standard desktop, response is a lot slower on 2.6.5 than 2.4.22. Not sure if I got something set wrong in the compile, but moving the mouse and stuff like that seems a lot jerkier under load. I use a USB mouse and keyboard, so maybe that's part of it. Anyone else seen similiar?
Can someone please explain how this is done in laymans terms.
This would be grate for my laptop, as the harddisk slows down the entire system. It takes like 30sec to load up mozilla. My laptop seems to spend half the time reading stuff from the harddrive. It takes 5sec to start xterm!
Obviously, this was stolen from SCO. This was based on their UNIX software and was available in the baseline from 10 years ago. It only shows that Linux, once again, is not an innovator, but just copies code from SCO to achive its scalability.
is accomplished by minimizing the disk head movement
I was always under the impression that modern hard drive designs hide the physical disk bits and pieces from the PC. So how can software predict where the heads are?
Karma? Hey I just call it as I see it.
1000% written as a decimal factor is 10.00, or a 10-fold improvement. When dealing with latency times measured in milliseconds, that's not too out of the ordinary. I'm no expert, but look at this situation: (someone correct me if I'm wrong)
Say, if a block is read on one end of the platter, then 10 subsequent reads are read in close proximity at the other end, followed by an 11th read at the beginning again, a predictive seeker could re-prioritize the 11th seek to be right after the first. That would cut down on quite a bit of head movement, as well as improve the seek time for that 11th block without negatively affecting the others too much.
The dangers of knowledge trigger emotional distress in human beings.
Try going outside. Find out about these things called "women".
Or switch to using BSD. Then you get computers and women.
ok, i know this is evil and all - but lets say MS decide to implement this as a concept (so without "stealing" code)... the linux community will have given them something and received (probably) nothing in return.
should open source initiatives be able to patent their ideas in a similar model to the way the GPL applies to their source code such that if someone implemented the IDEA, they would also have to release their version of the implementation source code.
just a thought...
>Try going outside. Find out about these things called "women".
And this would help my computer how?
I think Solaris 10 (or maybe a later version, I can't remember) is suppose to support a concept of Quality of Service applied to disk accesses.
Is anyone in the Linux world considering this ?
This is probably more applicable to the enterprise market, but surely any scheme of informing the scheduler about the expected disk transfer characteristics has to improve performance.
On the other hand, it might be just Sun trying to re-invent uses of buzz words to sell their products.
[ Monday is a terrible way to spend one seventh of your life. ]
*ugly* women? no thanks :)
Here's an older benchmark made by Andrew Morton showing the anticipatory scheduler vs the previous one.
The benchmark was made before 2.6.0, but I still think it shows the big difference from the 2.4 IO scheduler.
Quote:
Executive summary: the anticipatory scheduler is wiping the others off the map, and 2.4 is a disaster.
Just asking because I can't get this straight in my head. If a 1000% increase is 10x why is a 100% increase not 1x?
Mention the Lord of the Rings one more time and I'll more than likely kill you.
Doing direct IO can shave up to 30-50% of IO times on Solaris 9.
It's great watching the "modern" computer industry discover all the toys and optimisations that where essential engineering for the systems I used to use in the '70s & '80s.
All the wonderful stuff like disk seek optimisation, interleaved memory (Even MMU came to the moden computer about 15 years after everyone else had it) were technologies that made systems stand out from each other.
Because of the speed of things these days, lots of that tech has been largely ignored, until now when we're starting to hit hard performance barriers again. Now we have to invent the technology og the '70s all over again. It's nice to see all this stuff comming back though.
The NT scheduler has been O(1) like, eh, forever.
Our kernel produces far superior performance due to providing hooks for the COM layer
Yeah, whatever. There is no COM anywhere near the NT kernel, and the latest and greatest from Microsoft, the .NET framework, isn't even based on COM anymore
Nice troll...
Didn't Netware do this, oh, 15 years ago? I think it's called elevator seeking. What's old is new again.
Self awareness - try it!
Unless I'm mistaken, these disk read algorithms have been around for the past 20 years. I seem to remember studying them during my intro to O.S. class years ago.
"database data is generally grouped together and read in a big chunk"
It sounds like what your saying is that non database data on a disk is fragmented and that is why the head has to move all over the place.
Evolution or ID?
The cfq scheduler in the -mm (Andrew Morton) trees gives very good results in a desktop use.
With anticipatory or deadline, I'm experiencing awful skips with artsd under KDE 3.2 every time there is a heavy disk access, but it's [almost] completely gone with cfq.
To use it, compile a -mm kernel and add the 'elevator=cfq' to the kernel boot parameters through Lilo or Grub.
See this lwn article for more info.
-- don't discount flying pigs until you have good air defense
Let me start by claiming that optimizing desktop performanceis all about optimizing I/O patterns (contrary to what all Gentoo users think :P). My KDE startup is about three times as fast when I everything is in the disk cache, so it is clear where the bottleneck. (Just try logging in to KDE after boot, then log out and log in again.) A concentrated effort of
- passing on the right hints from KDE via glibc to the kernel (e.g. an madvise() call when loading executables giving the hint that probably most part of the file will be needed later on),
- trying some anticipatory reading of config files/libraries etc. from startkde where it is known that they will be needed, and that they are hopefully laying contigiously on the disk,
- optimizing disk layout for the common access patterns
would IMHO make a far bigger difference for the desktop experience than optimizing compiler flags by using gentoo or using a preemptible kernel.There has been a lot of discussion about this on the kde-optimize list (with Andrew Morton participating), so maybe we can hope that KDE 3.3 will offer some improvements.
As an aside, yes, we all hate the windows registry, but I think we should admit that for boot time optimization it is the right thing to do (having everything in one file that is layed out in one contigious block on the disk.)
She will scream at the computer in that nagging tone, thus the computer will haul arse and start moving faster.
AFAIK the "anticipation" bit is not so much about predicting head movement, but is more about reducing head movement. Reads
cause processes to block while waiting for the data (and can thus stall processes for long amounts of time if not scheduled appropriately), whereas writes are typically fire-and-forget. This last bit means that you can usually just queue them up, return control to the user program, and perform the actual write at some more convenient time, i.e. later. Since reads (by the same process) are usually also heavily interdependent, it is also a win to schedule them early from that POV.
That's my understanding of it.
HAND.
Alternatively, have multiple read-heads on a single arm. 3 would be a good number. The idea here would be that you could pre-seek either side of the disk, before finishing a read by the currently-active arm.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Doesn't this involve a green marker, and tracing along the edge of the hard drive? Faster and less distortion?
I always heard the Linux wasn't preemptive and that is why embedded developers shy away. Is this the first step towards resolving preemptive issues?
Also, It sounds like that if Linux had a defrag utility that the data could store data on the disk the way it would be accessed. If the OS would watch to see how the data is being accessed, it could then re-arrange the data dynamically. Example - you access File A which accesses File B and File C, the OS would recognize this and re-arrange the data in that order A, B, and C during low CPU usage times.
Your comment is meaningless gibberish studded with technobabble.
I believe you, you must really work at Microsoft.
This messing with the I/O queue may make things interesting for the journalling process which is kind of vital to integrity. File placement could become even more important for this (and also the placing of journal/log files).
The rest seems to just effectively be a modified elevator (wait a bit before moving).
See my journal, I write things there
And you're full of shit too. The O(1) scheduler is O(1) because it uses an O(1) scheduling algorithm, not because it "stores data directly into the registers".
Secondly, NT has been using a priority queue O(1) scheduler since at least version 4 I believe (maybe earlier?).
Thirdly, this isn't the O(1) scheduler here. It is the disk IO scheduler. But I'll let you off here because I assume you didn't read the story text, let alone the article.
Finally, what does COM have to do with anything? Linux doesn't use your crappy COM crap.
Zealotry is all fine and dandy, but delusional zealotry just lands people in jail.
You need help, buddy.
Would it not be possible to write a very basic adaptive network that "learns" what the best values for these parameters are for each individual machine, based on a history of its workload?
Invoicing, Time Tracking, Reporting
It's kind of sad that the free software advocates sometimes get so carried off by their pathological hatred for Microsoft and corporations that they don't see that they're about to become "the enemy" themselves.
Free is free. If you start to restrict the use and availability of your code by requiring the release of any modifications to the public, it's not free code anymore - no matter what RMS says.
The owls are not what they seem
"sometimes by 1,000 percent or more, [more] often by 2x"
/. insight (1/1000 of words)?
Nice mixed units - why not have 10x/2x or 1000%/200%?
Actually, we have a serious missed opportunity here: where is our folksy comparison unit? We have football pitches for length, African Elephants for weight, Libraries of Congress for volume and/or data. Where is a nice "just folks" ratio? Politicians promises (10x delivery)? Admans truths (100x reality), real virgins (1/1000000 of a porn site)?
Consciousness is an illusion caused by an excess of self consciousness.
... you help out then? If there are more tips n tricks out there, help to implement them if you have the skills and memory.
I could play mp3s just fine running 2.4 but with 2.6 my mp3s sometimes skip under heavy disk load. Maybe that has something to do with the switch to ALSA?
An Athlon XP with an Audigy2 shouldn't have any problems playing mp3s.
you had me at #!
Thanks but my father is Croatian and my Mom's French :o)
Anyway, you found out that I indeed am not a native English speaker, hence the neologistications.
Trolling using another account since 2005.
2CPU.com has a Linux kernel comparison of 2.6.4 and 2.4.25 on a SMP system with interesting results.
Desktop Linux needs a scheduling policy specific to interactivity. I guess this may happen the day a decent interface gets slapped on the Linux base. Until then, we dance the same dance - every release is faster than the previous one by the benchmarks, and feels more horrid than the previous one.
Surprise, the Mac has the same reactivity problem now thanks to its Unix (Mach) kernel, while the previous Mac OS 9 crashed regularly, couldn't multitask, but has a much snappier user-experience. Apple has been adressing this issue - which they recognize- for 2 years now, and have almost but not quite fixed it with their current Panther release.
It is time we found a way to benchmark a user experience in order to prevent over-optimisation for number-crunching.
Most of my posts get marked down as trolls - think hard: How can you solve a problem if you refuse to admit it exists ?
This is not a signature.
Yeah, the same thing happens under Windows if you read from CD-ROM. The whole thing just slows to a crawl if you try to read two files at once. I'd assume it's a hardware problem, (long seek times, large error margins) not necessarily Windows' fault, but I don't use CDs much anymore (hooray for ethernet and huge hard drives) so I don't know.
Of course, this raises the point that aligning the data on a game CD or DVD for a console is a science in itself. PC game development is easy in comparison! (plonk everything on the hard drive)
phil
...that the Red Hat "kernel development systems engineer"'s name is Stephen Tweedie, not Tweed :)
A friend of mine who does desktop work on Linux exclusively (lot's of developement) recently compiled himslef a 2.6 kernel and reports a very large, noticable increase in overall speed.
I'm using Debian Woody with a Nvidia Patched 2.4 kernel, so I'm reluctant to go through all the backporting and Nvidia recompiling fuss, but I'll guess I'm gonna do it sooner than I initially thought.
We suffer more in our imagination than in reality. - Seneca
No, this is not the elevator algorithm. This is an anticipatory algorithm that pre-queues reads that it expects the application to do in the future. Linux already has the elevator algorithm - had it before Windows, I believe.
Consciousness is an illusion caused by an excess of self consciousness.
However, I wouldn't even try that on RedHat or Mandrake without having the .config file and a list of distribution specific patches.
This was on a Celeron 1GHz laptop, and honestly, I couldn't tell the difference in speed beyond any custom compile. Custom meaning unnecessary device drivers are removed, and the ones that I need are compiled in (as opposed to remaining modularized).
Kinetic stupidity has a new brand leader: Allen Zadr.
so how does this effect IDE drives in terms of IO read/write accuracy? We use SCSI drives for low level mass data processing and mining because what you write to the disk is guaranteed to be what you can read from the disk in the future.
IDE disks don't have the same guarantee. Does the new 2.6 kernel improve this?
I also wonder if this reduces hard drive wear for longer lifetimes....
Veni Vidi Vici
I guess that makes the BSOD scheduler O(-1) or so - the more you use the computer, the faster that scheduler works.
M.
--
Monete Italiane
Elevator seek (which has been in Linux for a while btw) looks at the current request queue, this is about anticipating future requests.
And if you look above to this post, you can all see a great deal of decent explanations of what 1000% increase actually means (11%).
Kinetic stupidity has a new brand leader: Allen Zadr.
I haven't noticed the difference myself, but then again - if this is a new trick, and I've been running 2.6.4 for a month and 2.6 was first released several months ago...how is this a "New Linux Speed Trick"?
Kinetic stupidity has a new brand leader: Allen Zadr.
Trouble is, it is easy to implement when you have precise control over the disk heads positionnings, which was the case with the "old" ST and ESDI interfaces, where the OS directly specified a head and track/cylinder and sector number.
But nowadays, with EDI and SCSI drives that only have absolute sector numbers and automatic bad sector remapping, it becomes harder to specify directly the precise exact mechanical movement and thus optimize it.
And there is so much optimization a drive firmware can do, because only the OS will truly know for sure what's scheduled next in terms of disk space.
This is what sys/io.h has to say about direct IO:
/* If TURN_ON is TRUE, request for permission to do direct i/o on the
port numbers in the range [FROM,FROM+NUM-1]. Otherwise, turn I/O
permission off for that range. This call requires root privileges.
Portability note: not all Linux platforms support this call. Most
platforms based on the PC I/O architecture probably will, however.
E.g., Linux/Alpha for Alpha PCs supports this. */
extern int ioperm (unsigned long int __from, unsigned long int __num,
int __turn_on) __THROW;
Note again the bogosity about having to be root to use this.
And while we're on the subject of IO, does Linux offer a true kernel-trap implementation of Posix asynchronous IO calls like aio_read() or lio_listio()?
But at least, 2.6 can play an MP3 while swapping...
Aside from much better I/O performance, 2.6.x also has much better performance on my notebook (IBM T-series ThinkPad).
I don't know if it's due to SpeedStep support being in the kernel or what, but when I was running 2.4.x with the pre-emptible kernel patches, switching from wall power to battery power meant massive slowdowns, as though I had switched from a PIII-1GHz to a 100MHz Pentium classic. Simple commands like "ps" would take seconds to complete and screen redraws were visible. The whole system would feel like sludge. In spite of this fact, battery life was relatively poor. The combined effect (much slowed system, very short battery life) meant that it was difficult to get anything at all done on battery power.
Now with 2.6.x, when I switch to battery power, there is no perceptible slowdown whatsoever when compared to wall power, and battery life is much improved. Downside: suspending 2.6.x kills USB-uhci, so I've had to compile it as a module and hack up my suspend/resume scripts to reload it each time. But for the speed increase, it's well worth the trouble.
STOP . AMERICA . NOW
It is new with respect to 2.4.x. The anticipatory scheduler was introduced 2.5.x-mm and made its way into the kernel by the time 2.6 was released.
Program Intellivision!
...but it's not an explicit kind of think...
Dmitri? Is that you?
This seems a bit like hot air. I've tried 2.6 on a couple of systems and noticed NO speed improvements at all.
There seem to be a heck of a lot of people saying things like this article, and generally hand waving in a "kernel 2.6 will usher in the age of the linux desktop" manner.
It would be really wonderful if someone could provide concrete examples as to WHAT is 1000% faster.
Hell, I'd even settle for knowing which app(s) are 2x faster. I can not understand why such things (if true) were left out of the article.
You're making the standard mistake of assuming that the labor pool of "people who work on linux" is of a fixed size, and that man hours are interchangeable.
Linux doesn't work like that. The vast majority of people who work to improve linux aren't doing it because they're getting paid, and instead work on or focus on what interests them. If someone is focusing on feature X, that's not necessarily taking any time or energy away from feature Y - if they weren't doing X, they might very possibly not be contributing to Linux at all.
Seriously, complaints like this remind me of a manager coming in and discovering that some developers were talking about the finer points of thread interactions in a specific application and saying: "Who cares how the threading works? I just want something the customers can use!"
If it makes you feel better, you should learn to simply ignore discussion of technical features that upset you - this discussion does not in fact take away from discussions of user friendliness nor does it imply that the user will be forced to follow this discussion in order to use the outcome. If the user wishes, anyway, to follow this discussion then they might glean something interesting from it, but supplying the users with extra optional information can't be a bad thing, can it?
And as for access time, I have to ask: making the computer as a whole more responsive to my actions won't make me like using it better? Maybe 10% isn't going to make much perceived difference most of the time, but when it means the difference between a stutter-free movie playback and the occasional dropped frame, I'm going to notice.
It is.
It is 100% percent faster a whole 1 time faster.
So that makes whatever it was doing twice as fast now, right?
So it's 200% faster or 2x as fast.
eh, still confused/
I don't know the meaning of the word 'don't' - J
>>Try going outside. Find out about these things called "women".
>And this would help my computer how?
Your keyboard would sure be a LOT cleaner...
You DARE talk positively about ANYTHING Microsoft?
I'll have the editors lop off your karma, do you hear? Lopped off!!!
Fragmentation is a horror of Microsoft.
If you compile GLIBC with NPTL support you'll see even more of the new kernel in action. I quote from LinuxJournal.com,
NPTL brings an eight-fold improvement over its predecessor. Tests conducted by its authors have shown that Linux, with this new threading, can start and stop 100,000 threads simultaneously in about two seconds. This task took 15 minutes on the old threading model.
Shoot, I remember debugging the elevator seek driver for Interdata/Perkin Elmer/Concurrent OS/32 systems in the late 80's. This isn't new technology, not even for Linux. Remember the code that Tivo released back to the community? It was their implementation of an elevator-style seek mechanism for their PVR's.
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
I run the 2.6 kernel, in a RAID1 (a partition mirrored on two drives) configuration. How does this neato scheduling algorithm work with RAID? I suppose with RAID1 it simply makes writing on each individual disk faster, because the disks are treated as individual units, but what about RAID0/4/5 ? Or, does RAID not have any effect, because it's higher level than actual disk-writes? Yeah I suppose that's probably right..
I've seen people here trash Windows for a lot of reasons, but come on! Every version of Linux I've tried takes many times as long as Windows to boot. Windows comes up much faster than Linux in every case I've seen. I understand why you want so much uptime on Linux because it's such a pain in the arse to wait for it to boot.
We may experience some slight turbulence and then...explode. -Capt. Mal Reynolds
Do you ever question what "boot" means"? When a linux system lets you log in, EVERYTHING is already started and running. When Windows shows you the desktop, there is still a ton of stuff getting started in the background (or the foreground even) and it's still unusable. Windows doesn't start any faster, it just shows you pretty pictures sooner.
My blog. Good stuff (when I remember to update it). Read it.
We implemented something very similar to this years and years ago at a company where I used to work. It sped up certain operations mightily. However, nothing comes for free. We found that it improved throughput at the cost of responsiveness. A great thing if you don't have users waiting for "ls" to finish, sitting at their shell window. A very bad thing if you do. It's the age-old tradeoff of throughput versus responsiveness. Just imagine a slider between the two poles, and set it where you want it. But you can't have both, unless you find some way to remove outright inefficiency, which doesn't seem to be what they've done here.
Who here remembers SimTower? :)
The World Wide Web is dying. Soon, we shall have only the Internet.
ioperm(2) isn't for disk reads, but rather for accessing memory slots.
And why, oh why, must Anonymous Coward have to act as if it knew about stuff, without even trying to google said stuff?
blah
And we all would have benifited from this if they simply shared in the first place instead of spending 20-30 years "rediscovering" it.
One programmer likened the 70-80s as The Dark Ages. There were cabals and secret voodoo that people sat on and didn't share and you ended up with an ignorant masses that only thought "this is as good as it gets". Hopefully this renaissance sticks because it doesn't matter how good or cool your technology is if you bury it for 20 years without another person knowing.
Every person I've ever met that used an Amiga said they were perfect in every way.
Are you sure that you could slow the system down? Maybe you were using some hard-core mind-altering drugs back then....
The original research for anticipatory disk scheduling was done at Rice University by Sitaram Iyer and Peter Druschel and is described here.
Those are some benchmarks posted by the developers, developers, developers....
n ch+group:fa.linux.kernel&hl=en&lr=&ie=UTF-8&group= fa.linux.kernel&selm=fa.citnj0l.th62p7%40ifi.uio.n o&rnum=7
n ch+group:fa.linux.kernel&hl=en&lr=&ie=UTF-8&group= fa.linux.kernel&selm=fa.cjtrj8p.vh22h3%40ifi.uio.n o&rnum=1
n ch+group:fa.linux.kernel&hl=en&lr=&ie=UTF-8&group= fa.linux.kernel&selm=fa.cithjp0.thc0h6%40ifi.uio.n o&rnum=4
http://groups.google.com/groups?q=io+scheduler+be
http://groups.google.com/groups?q=io+scheduler+be
http://groups.google.com/groups?q=io+scheduler+be
Read that again. It's not 11%, it's 11x. In words: eleven times.
The Tao of math: The numbers you can count are not the real numbers.
When the kernel went 1.2, I think it was RedHat 2.X at the time, I remember discussing that with people on Usenet: Half of us complained about interactivity - the other half said "but the benchmarks are better". There was clearly some subjective issue which the benchmarks missed.
:Upgrade your hardware while freezing the software version :(
A good example of interactive fluidity is what happens when you resize a browser window when the system is under load - does it move immediately ? Does it move smoothly ? If it "waits" for several seconds before resizing, your user-interface analogy breaks down completely.
This said, the user experience is not really improving as far as I know. Bloatware is killing Linux a Gigabyte at a time. The only way to get faster reactivity seems to be
------------>
Microsoft firmly believes its system designs are stable and secure. Apple believes its systems are good value for money. Linux people believe their systems are designed for user friendliness.
This is not a signature.
I have an ancient computer - a K6-2 450mhz with 192 megs of PC100 RAM - and Mandrake 9.1 was a dog on it.
Later I switched to Slackware and it was much faster. Then I upgraded to Kernel 2.6.x (currently 2.6.5) and KDE 3.2.x and things are even faster now.
I suppose that Mandrake is too big/bloated (depending on if you like it or not) for old computers.
Treehugger? Treehugger... Treehugger!
install 2.6 on your rh9 or fed 1 machine in about 10 minutes....
/etc/yum.conf
http://people.redhat.com/arjanv/2.5/readme.txt
short version?
put this in your
[2.6testkernels]
name=Test Linux 2.6-test prerelease kernels for RHL9/rawhide
baseurl=http://people.redhat.com/arjanv/2.5/
yum install kernel
If you don't care about last access times on your files, then you should consider mounting your filesystems with the noatime mount flag as in this /etc/fstab line:
Reading a file under noatime means that the kernel does not need to go back and update the last access time field of that file's inode. Sure, multiple reads over a span of a few seconds will only cause the in-core inode to be modified, but eventually that modified inode must be flushed out to disk. Why cause an extra write to the disk for a feature that you might not care about?
For example: think about those cron jobs / progs that scan the file tree (tmpwatch, updatedb, etc.). Unless you mount with the noatime option, your kernel must at least update the last access time fields of every directory's inode! Think about those /etc files that are
frequently read (hosts, hosts.allow, DIR_COLORS,
resolv.conf, etc.) or the dynamic shared libs
(libc.so.6, ld-linux.so.2, libdl.so.2, etc.)
that are frequently used by progs. Why
waste write-ops updating their last access
time fields?
Yes, the last access time field has some uses. However, the the cost of updating those last access timestamps, IMHO, is seldom worth the extra disk ops.
There are other advantages to using the noatime mount option ... however to
wind up this posting I'll just say that I
always mount my ext3 filesystems with the
noatime mount flag. I recommend that
you consider looking into this option if you
don't use it already.
chongo (was here)
You may jest, but you should bear in mind that if because of what you've said, someone goes and creates a partition for /etc, they could well right royally SCREW up their system.
A lot of the content of /etc needs to be available early in the boot process such as /etc/inittab. If you WERE to do this you would be advised to use an initrd to mount /etc before init launches.
Otherwise you can have the (fun, fun) headache of synchronising a copy of /etc/inittab and /etc/fstab (not to mention the content of /etc/rc.d and /etc/init.d if you don't use the old monolithic inittab style) from the /etc partition to the / partition at shutdown...
I've done something similar on a machine that was tftp booted with a ramdisk image. It's /etc directory was symlinked into an AFS location where the files were stored on the network, along with a copy of boot-critical files and directories placed in AFS's mountpoint for before afsd is run, although it did end up being VERY messy when I mixed it with large amounts of functionality like kerberos support (which meant adding in time synchronisation)... you get the picture.
In conclusion, I'd say that it's not really worth it. After all, your /etc is just about the only thing on / that DOES change.... your /bin, /sbin and /lib shouldn't change much. Also, /usr /var /tmp /boot /opt (if your distribution has it ) and /root (if it's used at all) should all be seperate partitions.
Likewise, /mnt and /dev rarely change. If you run an AFS server, vicepa, vicepb.... etc until viceiv MUST be partitions in their own right.
I know what I mean. Anyway, I pointed to the right thread, so that the full discussion can be had.
Kinetic stupidity has a new brand leader: Allen Zadr.
I'll take the Linux women over the BSD women any day.
3 .php
http://www.linuxforum.com/linux_wallpapers_full/5
#include "sig.h"
I know there is a boot-time switch for changing the I/O scheduler, but I still believe you are stuck with one for all devices. How about using different algorithms for different partitions? There is quite a lot of difference between a database device, a filesystem holding binaries, shared libaries, /tmp, spool directories etc. etc. etc. When I/O schedulers are so different in their theoretical foundations, why do you have to choose only one?
This should be a mount option, not a boot option.
What is the sound of one hand clapping?
cat
It was added to kernels 2.6 and 2.4.24 perhaps, but the patches and distributions that support it out of the box have been around much longer than that. SUSE 8.0 supported it out of the box for instance. The linux-xfs mailing list archives go back to February 2000. So, XFS on linux is hardly a new thing.
Your computer will be much more stable.
(Because you won't be able to upgrade it often.)
Nothing to see here; Move along.
This is all very true. Not moving the disk head is everything.
In fact, my research group discovered this years ago - and precisely because of this we developed a hard drive with a single track. It had 65,536 heads and was very fast.
It was also about two city blocks in diameter. It got torn down because we were violating municipal building ordinances. Shame.
The problem with multiple partitions is that unless the partition is nearly full the head may be seeking back and forth across a lot of empty space. Unless you can put different partitions on different drives, it's probably more efficient to structure your filesystem something like (assuming a desktop):
/var/home symlinked by /home)
/var/home, whose head movements won't be desturbed by seeking to swap. Also remember that not only is seeking a big performance hit, the outside of the disk (usually low numbered sectors) has a higher transfer rate
hda: (boot)|(swap)|(/)
and if a second drive is available:
hdb: (/var, including
Thus the head is mostly over swap and the full portion of / . If there's any multimedia files etc, they should hopefully be under
Good reading if you are interested in this sort of thing
Linux Kernel Development
I have tested the Linux kernel 2.6.x series using the fastest Linux distro, Slackware, (I customized it and compiled it) and FreeBSD still runs faster with the defaults settings (no tweaking).
I have tested the Linux kernel 2.6.x series using the fastest Linux distro, Slackware, (I customized it and compiled it) and FreeBSD still runs faster with the defaults settings (no tweaking!).
I have tested the Linux kernel 2.6.x series using the fastest Linux distro, Slackware, (I customized it and compiled it) and FreeBSD still runs faster with the defaults settings (no tweaking)
I have tested the Linux kernel 2.6.x series using the fastest Linux distro, Slackware, (I customized it and compiled it) and FreeBSD still runs faster with the defaults settings (no tweaking) !
I agree with this...
I have tested the Linux kernel 2.6.x series using the fastest Linux distro, Slackware, (I customized it and compiled it) and FreeBSD still runs faster with the defaults settings (no tweaking!).
Try using KDE under FreeBSD and things will be faster than ever!
Anticipatory scheduling:
A disk scheduling framework to overcome deceptive idleness in synchronous I/O (2001)
Sitaram Iyer, Peter Druschel
18th ACM Symposium on Operating Systems Principles
ACM portal
Using the old citeseer trick, you can read the PDF version here:
Citeseer paper version
PDF version
Don't SLASHDOT citeseer!
There is more than one citeseer mirrors, use google:
Google Citeseer paper search
Enjoy!
Does anyone know what *BSD and Darwin have in this area? Lagging behind? Far ahead?
This Finnish word:o han"
"epajarjestelmallistyttamattomyydellaansak
is a contrived example. It was probably invented in a competition to create the longest possible grammatically correct Finnish word.
Trying to parse it is challenging even to a native Finn like me. Even though the suffixes in that word are properly formed and grammar rules won't prohibit using them together, it won't necessarily make sense. I can spot at least a double negative in that word, which is bad style at the very least.
In short, this word is a Christmas tree packet for Finnish language.
This kind of reminds me of the arguments about how fast IE comes up vs how fast Mozilla comes. The former, "being part of the Windows OS", gets a head start from preloaded DLLs.
At one point in the past I recall a KDE investigation into why preloading shared libraries might help cut down on slow response that people were seeing with g++.
Do all the mechanisms with ld.so cache help to get shared libraries ready (in a memory buffer) before any program starts, say based on the last accessed or most frequently accessed libraries?
"Provided by the management for your protection."
Tripleplus unstrong.
To be precise, you get *one* BSD woman. Do you really want to share her with the whole BSD core team? Ew.