On Fri, 1 Sep 2000, Linda Walsh wrote:
> Perhaps an "easy" way to go would be to convert block numbers to
> type "block_nr_t", then one could measure the difference that 10's of
> nanoseconds make against seeks and reads of disk data.
True for DOS.
On Linux, most file operations are done in RAM and only a part of them
ever committed to disk. And anyway, even if the process doing disk
I/O has to sleep, the sooner it releases the CPU, the better. Other
processes maybe need just CPU cycles, so why waste them? On a single
user, single task system I agree that the FS code could run seti@home
while waiting for disk seeks to complete... B-)
> Obviously the effect would be greater on ramdisks, but on computers with
> equivalent generation hard disks we might be talking something non-measurable
> or at least down in the noise level. Even transfers of 512 bytes of
> data from a buffer to user space is going to take significantly more cycles.
Again, it may take 100 cycles to do the job, but it doesn't mean you
can make them 110 and be happy. The *user* who's waiting for I/O won't
notice. Others will.
I agree that if you are certain that a piece of code will run once a
second, it doesn't really matter if it takes 100 cycles or 110...
you're loosing 10 cycles per second. But are you sure that all the code that
would use 'block_nr_t' is in such a slow path?
> If the change became as simple as changing a typedef in a file, then you
> could even allow a user to choose to allow "very large files" -- compiling
> with long long when turned on, or simple ints when turned off -- if that
> was seen as a necessity -- but I'd still lean toward it not being noticable.
>
> -l
>
> --
> Linda A Walsh | Trust Technology, Core Linux, SGI
> law@sgi.com | Voice: (650) 933-5338
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:10 EST