On Wednesday 20 April 2011 21:06:09 Alan McKinnon wrote: > Apparently, though unproven, at 15:41 on Wednesday 20 April 2011, Joost > > Roeleveld did opine thusly: > > Alan, > > > > I would love to do a better test then this. > > Reason I took Openoffice is because it's known to be a large build > > (requires a lot of diskspace) and takes a long time. > > > > If you know which other ebuilds might make for a better test, I will be > > happy to redo the test with those. > > Completely off the top of my head, I can't think of anything that > extensively uses disk space while compiling. There is the configure step, > and that hits the disk pretty hard, mostly reads. Building all of KDE > would fit the bill for disk IO methinks. > > However, you will also hit that infernal disk cache issue and render the > test useless (it's all in RAM anyway after the first read!). So you would > have to disable that. > > I don't know how to disable disk caching :-( > Maybe you can't, the kernel is clearly designed to use the feature if it > can at all. Maybe there's a knob in /proc you can twiddle. > > Any kernel knob experts around?
No expert here of course, but as long as we are talking about disk buffers hdparm used to be able to enable/disable read aheads (A1/A0). Not sure if sdparm does the same for SATA drives, or indeed if it contains any such option. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
