Re: [Evms-devel] Hardsector sizes

[Greg L. <gr...@le...>]

On Friday, 20 July 2001 at 13:38:55 +1000, Andrew Clausen wrote:
> On Fri, Jul 20, 2001 at 11:40:44AM +0930, Greg Lehey wrote:
>>> So what?  The CPU may be in demand for other things.
>>
>> So this doesn't happen very often.  If you're performing, say, 5000
>> transfers a second, that might translate to 10,000 divisions.  On even
>> the slowest ia32, this doesn't make it out of the noise.
>
> * clausen wouldn't know.  Rik seems to disagree ;)

I suppose I should look at the code before I say too much more.  I'd
be interested in Rik's opinion.

> Anyway, you're saying there are roughly 2 divides per
> transfer... (one for offset, one for count).  I'm not clear how this
> interfaces with everything else...

Neither am I :-)

> BTW: it's not "per transfer"... presumebly you need the math if you
> access the (buffer) cache too.

OK, I'm going from Vinum, which is below the buffer cache.  There's a
basic issue here that the rest of the system is still sector-oriented.
I suspect that that will change some time, and in the meantime
anything which is byte-oriented will need to interface.

>> That would be one way to do it.  It would make the compiled module
>> rather dependent on the environment.
>
> Why?  You would always maintain log_block_size and block_size...
> just a module that has been compiled with optimizations would assert
> at initialisation time that block_size == 1 << log_block_size.
>
> So, you maintain compatibility, between both versions of modules
> if they need to interface each other.  If you see a "MODULE_X: weird
> block size", you just recompile MODULE_X.

Sure, this will work, but it's is not the sort of thing that end users
will want to do.

Seriously, there are so many more significant ways to improve
performance than to eliminate division.

Greg
--
Finger gr...@le... for PGP public key
See complete headers for address and phone numbers