Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The New Linux Speed Trick

CmdrTaco posted more than 10 years ago | from the benchmarking-the-beast dept.

Linux 426

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

Sorry! There are no comments related to the filter you selected.

lol fp suckers (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8778281)

haha lol

You did it ! Get punished NOW !!! (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8778292)

Who [filmhobbit.com]
will like this movie? Nerds. Huge flaming nerds who live in their
parents basements and collect bad comic books written about superheroes
that most of the world has never heard of or for that matter will ever
care about. They'll buy into this thing because it turns all the right
pages and hits all the right tickle spots that they'll no doubt sit and
dissect as irony or subtle filmmaking, when in fact it is simply
contrived stupidity.

I kill Iraqi children for oil... (-1)

Stupid American (766263) | more than 10 years ago | (#8778285)

...because I am Stupid American

Re:I kill Iraqi children for protection.. (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8778330)

because they would only have become future terrorist.

Wow (-1, Offtopic)

igloo-x (642751) | more than 10 years ago | (#8778287)

I've only just noticed, too.

Linux Speed (Or Lack Thereof) (-1)

Sla$hd0tSux0r (762264) | more than 10 years ago | (#8778288)

It seems to me that any kernel that can claim 1,000x speed improvements must either be (a) very early in development, (b) written by a bunch of monkeys who don't know shit about writing an OS, or (c) written by a bunch of teenagers in Russia living in their parents basement.

Most likely a combination of all 3. My recommendation? Try going outside. Find out about these things called "women".

Re:Linux Speed (Or Lack Thereof) (0, Troll)

Anonymous Coward | more than 10 years ago | (#8778310)

A 1000 % increase isn't a multiplication by 1000, you lousy troll...

Re:Linux Speed (Or Lack Thereof) (1, Funny)

Anonymous Coward | more than 10 years ago | (#8778372)

Try going outside. Find out about these things called "women".

Or switch to using BSD. Then you get computers and women [spilth.org] .

Re:Linux Speed (Or Lack Thereof) (1, Funny)

Anonymous Coward | more than 10 years ago | (#8778399)

*ugly* women? no thanks :)

Re:Linux Speed (Or Lack Thereof) (5, Funny)

Eastree (719351) | more than 10 years ago | (#8778386)

>Try going outside. Find out about these things called "women".

And this would help my computer how?

Re:Linux Speed (Or Lack Thereof) (0)

Anonymous Coward | more than 10 years ago | (#8778488)

She will scream at the computer in that nagging tone, thus the computer will haul arse and start moving faster.

I can increase my Linux GUI 10,000 times (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8778293)

by switching from Gnome to KDE.

Goddamnit (-1, Offtopic)

JosKarith (757063) | more than 10 years ago | (#8778295)

First in here and I can't think of anything pithy to say...Damn!

Linux Speed (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8778300)

It seems to me that any kernel that can claim 1,000x speed improvements must either be (a) very early in development, (b) written by a bunch of monkeys who don't know shit about writing an OS, or (c) written by a bunch of teenagers in Russia living in their parents basement. Most likely a combination of all 3.

My recommendation? Try going outside. Find out about these things called "women".

Reposted as an A/C for higher karma

I've noticed it... (5, Interesting)

Anonymous Coward | more than 10 years ago | (#8778302)

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.

Re:I've noticed it... (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8778391)

You want data - I got data!

It's not the right data? Guess that's what happens when you minimise head movement.

Re:I've noticed it... (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8778455)

Well, upgrading will not automatically give you a faster computer, not for all hardware. On my old Compaq Armada laptop (450 mhz, 128 mb), Mandrake 9.2 using the 2.4 kernel and KDE 3.1 was slow but usable... same with Win2000.

I upgraded to Mandrake 10.0 Community Edition (you know, post-beta but not officially released...). It has kernel 2.6 and KDE 3.2. Looks nice, but now it is slow enough to be unusable. Mozilla takes 20 seconds to start, HD swapping furiously.

I believe I read that the new kernel does take up some more memory, perhaps my laptop has reached its limit?

I am currently learning to compile the kernel, so I'm going to try to do a low-fat version with all unneccesary file systems, drivers et al removed. I should probably use just about anything than Mozilla and KDE also. Firefox plus IceWM perhaps.

Cache? (4, Interesting)

Anonymous Coward | more than 10 years ago | (#8778306)

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

Re:Cache? (0)

Anonymous Coward | more than 10 years ago | (#8778460)

No, it guesses what an application's *future* IO patterns might look like. If it is hitting cache most of the time, it might only be doing a few random disk IOs and the IO scheduler will pick up on that too.

Re:Cache? (0)

Anonymous Coward | more than 10 years ago | (#8778489)

I'm sure the IO schedular is separate from the cache. i.e. the IO is scheduled on a cache MISS, obviously.

You're misunderstanding something... (5, Informative)

warrax_666 (144623) | more than 10 years ago | (#8778490)

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.

SCSI (4, Interesting)

Zo0ok (209803) | more than 10 years ago | (#8778308)

Dont SCSI drives do this themselves?

Re:SCSI (2, Insightful)

NfoCipher (161094) | more than 10 years ago | (#8778338)

SCSI is still so expensive and an aging technology. The idea is to get more out of the cheap IDE drives.

Re:SCSI (4, Informative)

KagatoLNX (141673) | more than 10 years ago | (#8778474)

ATA is basically the SCSI protocol (the good part) over IDE. There's a reason why some SATA drives appear as SCSI adapters under Linux.

Expensive, yes. Aging, no. Ten years ago people said SCSI was the future. Now everyone runs it, they just don't know it.

IDE in its original form has never been able to keep up with a 10k RPM (or higher) disk.

I think what the parent post is alluding to is Tagged Queuing. Tagged Queueing allows you to group blocks together and tell the drive to write them in some priority. That sort of thing is used to guarantee journaling and such. Interestingly, the lack of this mechanism is why many IDE drives torch journalled fs's when they lose power during a write--they do buffering but without some sort of priority. You can imagine I was pretty torqued the first time I had to fsck an ext3 (or rebuild-tree on reiserfs) after a power failure.

The reason that the kernel helps even with the above technology is that the drive queue is easily filled. Even when you have a multimegabyte drive cache and a fast drive, large amounts of data spread over the disk can take a while to write out.

This scheduler is able to take into account Linux's entire internal disk cache (sometimes gigs of data in RAM) and schedule that before it hits the drives.

Re:SCSI (3, Informative)

B1ackDragon (543470) | more than 10 years ago | (#8778347)

Since it mentioned that the OS is keeping "per-process statistics on whether there will be another dependent read 'soon'", I really doubt the drive controller would even be able to do that, much less want to.

Re:SCSI (2, Informative)

pararox (706523) | more than 10 years ago | (#8778361)

As a college student, I feel proud to say I've access to a quad-Xeon SCSI machine; this bad thing truly burns.

I run WebGUI [plainblack.com] on this machine, which recieves some 3 and a quarter million hits per month. Nothing to raise the eye brows at; but check it: on this machine the average uptime value is some 0.80. My personal (p3) machine, running a BBS, mail, bittorent, and web service maintains a constant 1.3+.

I've guaged the importance of SCSI drives in the equation via a (sadly) messy, but soon to be SourceForged Perl program. The result, confirming that which I've heard repeatedly, is that SCSI drives truly make the difference.

Re:SCSI (-1)

Anonymous Coward | more than 10 years ago | (#8778397)

You siiir, are a moron. Fuck you. Please die. Thanks.

Re:SCSI (2, Insightful)

awx (169546) | more than 10 years ago | (#8778504)

I'm sure you mean load value, not uptime value. An uptime of 0.8 days isn't really that impressive...

Re:SCSI (5, Informative)

DuSTman31 (578936) | more than 10 years ago | (#8778469)

Yeah, I think so. IIRC it's called tagged command queueing - the drive can have multiple requests pending and instead of doing them first come first served, they're fulfilled in order of estimated latency to that point.

I believe Western Digital's recent Raptor IDE drives have the same feature.

The benefit of this seems contingent upon having multiple requests pending, which AFAIK is hard on linux as there's no non-blocking file IO. To me, this reads like a workaround for that.

It kindof Early to be Slashdoted (0, Funny)

stecoop (759508) | more than 10 years ago | (#8778309)

It seems that the server isn't running the speed improvment becuase its probably slashdotted.

The system was unable to communicate with the server.

Re:It kindof Early to be Slashdoted (1)

stecoop (759508) | more than 10 years ago | (#8778333)

Alright Its back... Whew its Yahoo page - that would be bad if Slashdotters could freeze that page.

1,000 percent? (2, Insightful)

lonegd (538164) | more than 10 years ago | (#8778312)

That seems rather high. Either something was broken/badly coded or someone's been adding a couple of zero's ;)

Linux Devices has an article on the 2.6 network features here http://linuxdevices.com/articles/AT7885999771.html [linuxdevices.com]

Re:1,000 percent? (0)

larien (5608) | more than 10 years ago | (#8778335)

My guess is that it's a fairly specific, non-standard load that will garner a 1000x gain. Think about how this would help 10,000 processes accessing 10,000 different files and reading in their contents; under a normal system, each process would get a short time to read data, then the next process etc. With the read-ahead, it's likely that the kernel would read in larger chunks of data at a time and cut down on disk seeks.

Re:1,000 percent? (5, Informative)

gowen (141411) | more than 10 years ago | (#8778356)

My guess is that it's a fairly specific, non-standard load that will garner a 1000x gain
My guess is that you haven't spotted that 1,000% is not 1,000x. A 10-fold increase isn't completely implausible for a workload whose read pattern matches the assumptions built into the anticipatory scheduler.

Re:1,000 percent? (3, Insightful)

aastanna (689180) | more than 10 years ago | (#8778341)

Seems OK to me, that's a 10x improvement, and that was the theoretical high end example. Since they said it would commonly increase speed by 2x, and 15% for databases, it seems right in line.

I suppose that since database data is generally grouped together and read in a big chunk there's less room for improvment.

Re:1,000 percent? (0)

Anonymous Coward | more than 10 years ago | (#8778388)

Are you saying that the speed increases are all in this guy's head. ;-)

Re:1,000 percent? (5, Informative)

tonywestonuk (261622) | more than 10 years ago | (#8778398)

Isn't 1000%, 11x?
15% = 1.15x
100% = 2x
200% = 3x
300% = 4x ..
900% = 10x
1000% = 11x

a % = (a+100)/100 x

Re:1,000 percent? (4, Insightful)

maxwell demon (590494) | more than 10 years ago | (#8778420)

1,000 percent is 10x, but 1,000% improvement, being improvement by 10x, is 11x as good.

Just as 50% is half, but 50% improvement is three halves as good.

funny? mods on crack. (-1)

Anonymous Coward | more than 10 years ago | (#8778480)

that's all.

Re:1,000 percent? (1)

warrax_666 (144623) | more than 10 years ago | (#8778443)

Well... a 1000% = 10 (by the definition of %), but a 1000% increase is equivalent to multiplying by 11. (As you correctly stated).

fragmented information (1)

millahtime (710421) | more than 10 years ago | (#8778442)

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

Not too unreasonable. (1)

mfh (56) | more than 10 years ago | (#8778371)

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.

Cool (4, Informative)

JaxWeb (715417) | more than 10 years ago | (#8778313)

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?

Re:Cool (2, Insightful)

Alrescha (50745) | more than 10 years ago | (#8778352)

"and there is a small delay before the head returns for a seek to see if the process requests another read."

It's early, but did read/write heads suddenly develop intelligence while I was napping?

A.

Re:Cool (-1)

Anonymous Coward | more than 10 years ago | (#8778459)

Insightful??? Fucking moderators on crack as usual.

-1 Pedantic Jerk more like...

Re:Cool (1)

CyberGarp (242942) | more than 10 years ago | (#8778387)

It may be more complex, but it works damn well. Squeezing an extra 30-40% out of my laptop doing disk i/o has been really worth it. Especially since I've been editing and processing 600M files on it lately.

Re:Cool (1)

MrIrwin (761231) | more than 10 years ago | (#8778392)

"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?"

Perhaps that is why the default setting is the one indicated for desktop users.

And yes, if I were using a Linux box for specific server tasks then I would tweak the settings to get a bit more performance out of it.

Re:Cool (-1, Troll)

dave420 (699308) | more than 10 years ago | (#8778492)

I think that's exactly what Ma & Pa want to choose when they first turn on their Wal*Mart linux box - what IO mode their HDDs should use.

If Linux is going to tackle the desktop, the priority should be to make it desktop-ready, surely... Adding extra features which don't add functionality that keeps people away is counter-productive.

whaaaa? (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8778315)

So now Linsux zealots are bragging about their "dick head movement"?

New Kernel? (-1)

SonicTooth (561342) | more than 10 years ago | (#8778317)

Wooo 1000x, where can i get this new kernel?

Re:New Kernel? (0)

Anonymous Coward | more than 10 years ago | (#8778336)

Well, nowhere. It says percent not times. So that would be 10x...

Re:New Kernel? (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8778344)

1000 PERCENT faster isn't the same as 1000 TIMES faster. It's more like like 10 TIMES faster.

Re:New Kernel? (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8778345)

Wooo 1000x, where can i get this new kernel?

No, 1000 percent. Ie 10x.

Re:New Kernel? (0)

Aadomm (609333) | more than 10 years ago | (#8778408)

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?

Re:New Kernel? (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8778380)

Has anyone mentioned to him yet that 1000% does not equal 1000x ? If not, I'd like to receive some karma please (thanks in advance).

Yay (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8778323)

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.

Re:Yay (0)

Anonymous Coward | more than 10 years ago | (#8778405)

Ah, I remember this too. It was funny, because Exchange, which I had always assumed to just be a slow crappy mailserver just needed that kick in the pants, and it really sped up.

Loading a huge mail database took forever and a half before sp4.

Re:Yay (-1, Troll)

timecop (16217) | more than 10 years ago | (#8778422)

why the hell is this flamebait?
Linux is getting these "filesystem optimizations" in 2004, and I remember windows 98 shipped with defrag with "intel optimizers" feature in it that rearranged files on the disk for faster access (after analyzing startup patterns of the apps). And they:ve had this for how long now? Windows 98 was out somewhere around 1998, I would imagine.

Nice to see Linux moving forward at an amazing pace.

Re:Yay (0)

Anonymous Coward | more than 10 years ago | (#8778430)

98 came out in 97, making your point that much stronger

Re:Yay (1)

Wiz (6870) | more than 10 years ago | (#8778491)

Errrr, this is nothing to do with the filesystems involved though! It'll work just as well on resierfs as ext2!

File optimisation as you describe it is completely DIFFERENT!!

Why not combine those two methods? (4, Interesting)

maxwell demon (590494) | more than 10 years ago | (#8778327)

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?

Re:Why not combine those two methods? (4, Insightful)

mirko (198274) | more than 10 years ago | (#8778365)

<joke>
what would you have expected the kernel 2.8 to bring you ?
</joke>

Basically, I think this is like the windows system settings : you either privilegiate front end services (GUI) or back end services (apache, etc) but you cannot do both because some would be optimized for reactivity, the others to handle the workload... like a ferrari and a truck... this doesn't work nor excel in the same way.

Re:Why not combine those two methods? (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8778429)

What sort of George 'verbal abortion' Bushism is " privilegiate "?
You (presumeably) wanted just 'privilege [reference.com] ' as a transitive verb:
you either privilege front end services (GUI) or back end services (apache, etc)

Re:Why not combine those two methods? (-1)

Anonymous Coward | more than 10 years ago | (#8778527)

Does one have to be George Bush to mispell English ?

Re:Why not combine those two methods? (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8778439)

like a ferrari and a truck... this doesn't work nor excel in the same way
Does Not? [barchetta.cc]

Re:Why not combine those two methods? (5, Informative)

Anonymous Coward | more than 10 years ago | (#8778381)

I believe that the anticipatory sched uses the model of the deadline sched. See "Linux Kernel Development" by Robert Love.

Our take on it from inside MSFT (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8778350)

For obvious reasons I am not going to say where I work in MSFT, but you will find this interesting.

We have been keeping a very close eye on the developments in the Linux kernel, particularly 2.6, and to be honest we find it pretty amazing.

What impressed us most was the way the new scheduling system stores data directly into the registers to achieve the O(1) timing, quite a leap forward that we had not even thought of!

Our kernel produces far superior performance due to providing hooks for the COM layer (definitely produces noticably faster performance to end users) but I can really see why the PHB's here are worrying about the direction the penguin is going on this.

Oh, come on... (4, Interesting)

mdb31 (132237) | more than 10 years ago | (#8778431)

...to achieve the O(1) timing, quite a leap forward that we had not even thought of!

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

Re:Our take on it from inside MSFT (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8778449)

really???

why is it that windows XP professional, your flagship.. is much slower than a linux install that is comperable like Mandrake 10.0 with an older 2.6 kernel??

benchmarking proves it also.. XP is doing some really hokey things.....

and I wont even get into the inability to be really multiuiser/multitasking and the gigantic security holes you guys think has to be there for the sake of "useability"...

sorry, but nothing in XP is impressive... it is nothing more than windows 2000 core with different clothes and exra bling bling.

Re:Our take on it from inside MSFT (2, Funny)

BCoates (512464) | more than 10 years ago | (#8778524)

Your comment is meaningless gibberish studded with technobabble.

I believe you, you must really work at Microsoft.

Interesting?? (-1)

Anonymous Coward | more than 10 years ago | (#8778525)

Shouldn't this be -1, troll ?

Amiga Disks (5, Interesting)

tonywestonuk (261622) | more than 10 years ago | (#8778351)


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

Re:Amiga Disks (2, Informative)

jtwJGuevara (749094) | more than 10 years ago | (#8778400)

Isn't this one of the reasons Windows takes ages to boot? (many processes all competing for the one disk resource?).

Which version of Windows are you referring to? While risking to sound like a fan boy here, I must say that the OS load times for XP are quite fast compared to previous versions and to most vanilla linux distributions I've tried in the past (Mandrake 9.x, Redhat8/9). Whether or not this is in relation to resolving two processes arguing over access to read from the disk, I don't know. Does anyone have any more information on this?

Re:Amiga Disks (0)

Anonymous Coward | more than 10 years ago | (#8778423)

Such is the way of one of the new scedulers - it waits a bit to see if an app wants more data, if it does then it won't serve another app. This only works on the small scale though, becuase there's no way for the OS to know if app2 needs to load before app1 - if it delayed for too long then app1 would keep the file open while it waits for app2, and app2 wouldn't come until the file was closed.

Re:Amiga Disks (3, Interesting)

MrFreshly (650369) | more than 10 years ago | (#8778467)

I think windows loads slow because of all the damn spyware and un-necessary default drivers and services and IE preloading...etc...

IMHO Default windows config is kinda like a Redhat with everything and then some.

Start in safe mode and watch all the crap that tries to load - a ton of it is not needed.

If you tighten your install by removing a lot of the extra services, spyware, and a few performance tweaks - you'll see a major speed increase over all.

I use XP, but I don't like it much anymore...It's stable, but I'm really looking forward to a better desktop for Fedora and the new Core 2 release.

I've found the opposite (2, Interesting)

redcliffe (466773) | more than 10 years ago | (#8778357)

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?

Re:I've found the opposite (1)

Nikademus (631739) | more than 10 years ago | (#8778370)

This is due to the fact you are probably still using /dev/psaux instead of /dev/input/mice.

Re:I've found the opposite (0)

Anonymous Coward | more than 10 years ago | (#8778414)

And that he has disabled harddisk DMA support in the kernel....

Re:I've found the opposite (1)

Outsider_99 (761534) | more than 10 years ago | (#8778456)

I found that my mouse was more responsive. That was the only performance difference betwen 2.4 and 2.6 for me

I'm an end user (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8778360)

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!

Stolen from SCO (3, Funny)

Anonymous Coward | more than 10 years ago | (#8778363)

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.

And tomorrow.... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8778364)

And tomorrow you'll learn that too many 0's on one side of the disk makes it too heavy, thus warping the disk. We'll also show you how to prevent that.

But how? (2, Insightful)

builderbob_nz (728755) | more than 10 years ago | (#8778368)

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?

Anti-MS Patent (0, Offtopic)

mydigitalself (472203) | more than 10 years ago | (#8778379)

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

Re:Anti-MS Patent (1, Informative)

Anonymous Coward | more than 10 years ago | (#8778395)

I believe this feature is in NTFS.

Re:Anti-MS Patent (3, Interesting)

Tribbin (565963) | more than 10 years ago | (#8778406)

Stealing what? The algorithms?

The end-(Windows)-user benefits from it.

That's the price of freedom.

And any additions MS makes to the code must be made public.

So then everybody benefits.

Re:Anti-MS Patent (3, Interesting)

mydigitalself (472203) | more than 10 years ago | (#8778448)

no: stealing the concept (probably by analysing the code) and writing it themselves.

so if MS make any improvements in their own implementation of the concept, then the code would not be made public and MS benefits and not everyone else.

to elaborate (and in some ways i believe this is what SCO are arguing), lets say i see an open source application that does something neat. it probably won't be patented because the author expects someone to contribute any modifications back. but lets so i don't because i'm a greedy commercial corporate and so i effectively copy the IDEAS behind the application. my code may look quite similar to theirs, but i certaintly have not infringed on the GPL (or have I - i'm no lawyer!).

so if this neat application had an "open source patent" in that anyone infringing on the patent would not be liable for millions, but rather they would be liable and forced to open up the source code of their particular implementation.

No...more...pr0n... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8778389)

In other news, the porn industry announced "increased speed is accomplished by minimizing the dick head movement during concurrent heads."

Disk Transfer QoS (4, Interesting)

johnhennessy (94737) | more than 10 years ago | (#8778394)

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.

Re:Disk Transfer QoS (0)

Anonymous Coward | more than 10 years ago | (#8778522)

This is the basic idea behind most schedulers. The old 4BSD scheduler is ridiculously good at this (for single processor systems) and some of the work from Timesys to make Linux into a hard realtime os is a good example in the real world. QoS, or making sure certain processes get their needed time, is basically what an embedded os's scheduler comes down to. This can be done in several methods and the Timesys Linux kernel supports this in several ways.

Benchmark (5, Informative)

zz99 (742545) | more than 10 years ago | (#8778403)

Here's an older benchmark [kerneltrap.org] 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.

When will Linux do direct IO? (0, Interesting)

Anonymous Coward | more than 10 years ago | (#8778424)

If IO speed is so important, why doesn't Linux do direct IO [berkeley.edu] , where the app's buffer is DMA'd directly to/from the device instead of getting buffered in the kernel?

Doing direct IO can shave up to 30-50% of IO times on Solaris 9.

Retro is still cool ? (4, Insightful)

Anonymous Coward | more than 10 years ago | (#8778428)

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.

what's old is new again (1, Insightful)

hb253 (764272) | more than 10 years ago | (#8778434)

Didn't Netware do this, oh, 15 years ago? I think it's called elevator seeking. What's old is new again.

OS 101 (1)

dioscaido (541037) | more than 10 years ago | (#8778435)

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.

CFQ (3, Informative)

kigrwik (462930) | more than 10 years ago | (#8778446)

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 [lwn.net] for more info.

Real benefits... (3, Insightful)

greppling (601175) | more than 10 years ago | (#8778470)

...for the typical desktop workload would come from a better cooperation between applications, glibc, and the kernel.

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

Speed-ups (2, Insightful)

jd (1658) | more than 10 years ago | (#8778495)

I've often wondered what would happen if such I/O speedups were put into hardware. There's plenty of RAM on modern controllers, but caching adjacent tracks is not as efficient as caching distant tracks, so as to minimise the need for moving the read-heads long distances.


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.

I think I've heard of this (2, Funny)

TheVidiot (549995) | more than 10 years ago | (#8778503)


Doesn't this involve a green marker, and tracing along the edge of the hard drive? Faster and less distortion?

Preemptive and Defragged? (1)

stecoop (759508) | more than 10 years ago | (#8778509)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?