Re: very low performance on SCSI disks if device node is in tmpfs

[Richard B. Johnson]

On Tue, 25 May 2004, Olaf Hering wrote:

>
> Any ideas why the location of the device node makes such a big
> difference? I always wondered why my firewire is so dog slow with 2.6.
> Now I know the reason: /dev is in tmpfs.
> I dont see that with IDE disks, only with SCSI.
>
> (none):/# /sbin/hdparm -tT /dev/sdb
>
> /dev/sdb:
>  Timing buffer-cache reads:   2532 MB in  2.00 seconds = 1264.93 MB/sec
>  Timing buffered disk reads:   48 MB in  3.12 seconds =  15.41 MB/sec
> (none):/# /sbin/hdparm -tT /tmp/sdb
>
> /tmp/sdb:
>  Timing buffer-cache reads:   2328 MB in  2.00 seconds = 1163.01 MB/sec
>  Timing buffered disk reads:   82 MB in  3.03 seconds =  27.03 MB/sec
>
> This happens also with 2.6.1-mm kernels. I attach the profile with
> devnode in tmpfs and on disk.
>
> --
> USB is for mice, FireWire is for men!
>

You are not actually reading or writing from the 'device'-files.
They are just a trick to associate a major/minor number with
a device. After that initial open, the fd is the handle by which
the device is accessed, not the device-files. Given this, it
doesn't make any difference if the device-file is generated
dynamically as in devfs or statically with `mknod`. Unless you
have a bench mark program that does:

             do {
		open();
		write();
		close();
		open();
		read();
		close();
                } while(forever);

If that's what the program does, it's probably not a good example
to be used as a bench-mark. If the program does that, and you
want to optimize for that, then the way a read is handled (for the
open in devfs), would need to be optimized to use non-paged memory
because it is possible, in principle, to have to page in the contents
of devfs for each access. Right now, kmalloc(GFP_KERNEL) is being
used and that's pagable.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/