On Apr 1, 2005 3:45 PM, Jack Coates <[EMAIL PROTECTED]> wrote:
Free Lunch wrote:
Hi,
... say, sure does take you a long time to get information out of your disk... hdparm -tT /dev/[your-music-disk] please?
I think you're on the wrong track. I am very picky about disk performance ;-)
First, this is unique to 6.X. Playlist sorting performance is poor in 5.4.1 but not nearly this bad.
First, the vmstat output shows the CPU being burned in User space, not
system. Waiting on disk would typically be shown as Sys or wait time. The amount of CPU time spent in user space suggests some serious code
churn.
what was the time interval on that vmstat? I wasn't even looking at the CPU, as it only got hit for three intervals, followed by twenty-four intervals of disk reading. See why I'm asking about your disk?
Regardless, it takes no time at all to stat(3) every music file in that list. Of course accessing the disk should be unnecessary since we're just re-sorting an in-memory playlist - right?
I think you're spending too much time on theory and not looking at the practical reports from your system. I haven't read the code closely enough to say what it ought to be doing at this point, but your vmstat clearly shows that you're reading disk. Lots of it, and slowly to boot.
The system can stat every file in the playlist in just over a tenth of a second. It is worth noting that the time to sort the playlist does not improve with subsequent attempts (the disk caching makes no difference). The file metadata is all in cache:
% time ls -lR >/dev/null 0.082u 0.041s 0:00.13 92.3% 0+0k 0+0io 0pf+0w
% ls -lR | wc 8476 62685 580699
/dev/hde1: Timing buffer-cache reads: 128 MB in 0.43 seconds =299.11 MB/sec Timing buffered disk reads: 64 MB in 1.15 seconds = 55.52 MB/sec
[EMAIL PROTECTED] tftpboot]# hdparm -tT /dev/hdc
/dev/hdc: Timing buffer-cache reads: 1520 MB in 2.00 seconds = 760.00 MB/sec Timing buffered disk reads: 134 MB in 3.00 seconds = 44.67 MB/sec
Maybe not picky enough about performance :) Granted that's a nice new 300GB disk, but I get similar numbers from a two-year-old 40GB at /dev/hda. Okay, how about -v?
[EMAIL PROTECTED] tftpboot]# hdparm -v /dev/hdc
/dev/hdc: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 36473/255/63, sectors = 585940320, start = 0
-- Jack at Monkeynoodle dot Org: It's a Scientific Venture... Riding the Emergency Third Rail Power Trip since 1996! _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
