| |||||||||||||
Being nicer to executable pagesBeing nicer to executable pagesPosted May 21, 2009 14:49 UTC (Thu) by nix (subscriber, #2304)Parent article: Being nicer to executable pages
Applications have other even simpler ways to receive preferable treatment for their file-backed pages: e.g. just keep referencing each page frequently. (Garbage collectors tend to do this already, admittedly generally for anonymous pages, but that isn't a requirement.)
And Alan's disks can do 50Mb/s, but can they do that if the incoming workload is very heavily seeky, as is often the case for major faults of pages from text pages of binaries and swap? I doubt it can manage more than 1--5Mb/s in that situation. Even prefaulting neighbouring pages isn't going to help too much there.
(Log in to post comments)
Being nicer to executable pages Posted May 23, 2009 23:07 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Alan's disks can do 50Mb/s, but can they do that if the incoming workload is very heavily seeky, as is often the case for major faults of pages from text pages of binaries and swap? I doubt it can manage more than 1--5Mb/s in that situation. I believe that was Alan's point. He's saying there's more to be gained by getting rid of seekiness than in getting rid of reads of executable files. I don't know if he had any particular approach in mind, but there are lots. For one thing, on a heavily loaded system, which is the kind on which we care most about performance, seek time disappears. The head can move over a cylinder way faster than the cylinder can turn under the head, and the only time we have long seeks is when there isn't enough work to choose from.
Being nicer to executable pages Posted May 24, 2009 11:29 UTC (Sun) by nix (subscriber, #2304) [Link]
You overestimate current drives. We can't hand it dozens of things and
say 'give me these back in any order you please'; the most we can do is give it a lot of stuff at once, and ask it to hand them back *in order*.
So under heavy load (especially heavy memory pressure or write pressure),
Being nicer to executable pages Posted May 24, 2009 14:55 UTC (Sun) by farnz (guest, #17727) [Link] You're definitely behind the times - both SATA NCQ drives and SCSI TCQ drives can handle commands out of order. PATA drives, SATA drives without NCQ, and SCSI drives without TCQ can't do this; it's also rare to find USB drives that do this. So, with a modern laptop drive, I can just shunt 31 commands at it, and let it handle them in the order that's most sensible for the drive. In practice, most drives I've encountered appear to have an internal elevator to minimise seeking; combine this with the deep Linux elevator keeping the drive fed with commands, and my laptop drive is very successfully maintaining a high throughput despite a rather seeky pattern.
Being nicer to executable pages Posted May 24, 2009 17:58 UTC (Sun) by giraffedata (subscriber, #1954) [Link] Command queuing in the disk drive (NCQ/TCQ) isn't really an essential part of eliminating seek time. It's main purpose is to eliminate the time you wait to generate a command, get it to the drive, and have the drive interpret it, which it does by allowing you to stream the commands in.Linux's ability to queue hundreds of I/Os and send them to the drive in block number order is where most of the seek time elimination happens. Even on modern drives, it's the case that seek time between to consecutively numbered blocks is usually negligible. But even so, we're just talking about what Linux already does -- the point is that it can conceivably do even more to make the disk see sequential block number I/O, and it might be a more profitable investment than trying to make it see less I/O by caching executable pages longer.
Being nicer to executable pages Posted May 25, 2009 15:39 UTC (Mon) by nix (subscriber, #2304) [Link]
SCSI can, sure, but I'd heard that SATA NCQ pretty much couldn't, that it
was notably less capable than TCQ. Obviously I heard wrong :)
|
|||||||||||||