On Tue, Oct 17, 2000 at 09:21:00AM -0700, Andre Hedrick wrote:
> On Tue, 17 Oct 2000, Larry McVoy wrote:
> > On Tue, Oct 17, 2000 at 11:23:30AM +0200, Vojtech Pavlik wrote:
> > > Well, I know quite well what this can bring us - with precise profiling
> > > we could see the exact geometry of the drive
> > LMbench has had something which does this for years. Look at
> > http://www.bitmover.com/bw.gif
> > http://www.bitmover.com/seek.gif
> Great, but that was via a file system.
actually, it was via a raw disk under irix. And block devices under Linux
show the same results if you flush the cache first. See flushdisk.c for
the Linux version of doing that.
> > The first shows you zone bandwidths, the second shows you a precise profile
> > of the access times; you can get everything you might want from that.
> > For example, the time quoted by all the drive people is 1/3 in from the
> > left, at the bottom of the curve - a fairly misleading number if you ask
> > me.
> > Bingo. Screwing around with the elevator is in general a waste of time,
> > but it is a rite of passage for all I/O people. I did it a long time
> Well let me drown!
Sure, I did it over the protests of other people and I learned something,
you have every right to do the same thing. In fact, it's great that you
are doing it. Just don't get all bent out of shape if you tweaking the
elevator alg does nothing (in SunOS under most workloads the default was
99.4% as good as every other one I tried, and I tried a bunch. I then
went to screw with the pageout daemon and learned a similar lesson:
paging out pages is insane, you want to page on inodes, but that's
a rant for another day).
> > ago and learned an important lesson: if your file system is good enough
> > (and most are) there is almost nothing that can be done to improve
> > performance - the file system has done all the work already. You're
> > welcome to argue that point, but please do so with traces of a real
> > system - not with your opinion. My opinion used to be the opposite
> > and the traces moved me to this opinion.
> Expand 'traces' ... O-SCOPE analyizer?
Insert a ring buffer into the disk sort entry point. Add a userland process
which reads this ring buffer and gets the actual requests in the actual order
they are sent to the drive[s]. Then take that data and write a simulator into
which you can plug in different algs. I have all this crud for SunOS if you
want it, including elevator.c, hacksaw.c, and inorder.c. Then you run your
test cases given what you know about seek time and rot delay and see what
your changes would do.
If you do all this, write a paper, Usenix loves this junk.
> How can LMbench access things that I can but a FS can not?
raw disks? block disks? both work.
-- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:11 EST