At 10:44 AM 2/5/2001 +0300, Dmitry Kuzmenko wrote:

>I've tested NO_BUFFERING ... So, it will be too complex to
>understand what performance user will got on his configuration
>setting NO_BUFFERING flag.
>
>If anybody interested, I can make a table with test results,
>but it was made on IDE drive. I'm sure that on SCSI drive there will
>be another results (very different from IDE).

I'd like to see the results. More than that, I'd like to see
the results on a variety of drives & configurations, hoping to
find some pattern to the results.

>p.s. have not tested IO_OVERLAPPED, because I've thought it's completely
>another thing than no_buffering.

Not completely. The idea was to be able to read ahead, to
increase the amount of parallelism. There's also code that
recognizes operations that are going to flush the cache and
restricts the amount of space they can use - I think that's
not turned on. For example, a select count from a large table
will currently read each page into a new cache buffer, leaving
the entire cache full of pages that are no longer of interest.
This code would restrict that operation to a few pages, improving
concurrent access. All very good things. All very untested.

>p.p.s. I think it is not a big problem to add no_buffering flag like
>force_write flag, and some kamikadze can use it on their own risk.
>I mean there can be some clever HDD controllers that will work better
>than OS cache. :-)

Adding switches like that violates Starkey's first rule of system
design:
"If you don't understand what it does, what makes you think your
customers will?"

Lets build it, understand it, and decide how it should be used.


Regards,

Ann
www.ibphoenix.com
We have answers.