Hi all,


After some searches on google, it seems that the value for NBUF in
these systems is limited to around 450MB.

If the above is correct, is there anyone that knows why this limit
wasn't increased with 5.0.7?
Technical explanation appreciated.

If incorrect how do we change it to be above that limit as some of my
colleagues would like to be able to do it.


Thanks all




Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

In article <ccqkkvkqv0q7i217f7oitvj6o4b2b7lc6e@4ax.com> real-email-in-msg-spam@email.com writes:
$After some searches on google, it seems that the value for NBUF in
$these systems is limited to around 450MB.
$
$If the above is correct, is there anyone that knows why this limit
$wasn't increased with 5.0.7?
$Technical explanation appreciated.

I don't know the kernel innards; only someone like Bela or John
would be able to post an answer that is based on definitive
knowledge of this (and quite probably also definitive knowledge
of engineering discussions about what things ought to be changed
in various OS releases).

But here's a guess. Most data structures include both the data
itself (the buffer, in this case), plus some kind of administrative
overhead - linked lists, information about just what actually is in
the data (like whether the buffer in question is dirty, which block on
which device has its contents in this buffer), and so on.

Most system limits in binary computers are powers of two.
512 MB is a power of two. Each buffer is 1 kB, plus whatever
the overhead is. Multiply that by 450 000 (the limit for NBUF)
and I'm guessing you'll get slightly under 512 MB.

Now, why there's a 512 MB limit ... dunno. There's a 4 GB
addressing limit on the 80386. Yes, this has been increased in
more recent CPUs, but OSR5 is fundamentally a 386 OS, and
while the minimum system requirement is a Pentium, it also states
that customized versions will run on 386 machines, so the kernel
must still be 386 code with support for later CPUs. So this
512 MB probably relates to some kind of memory layout that
was designed in the 386 days. This layout may be so deeply
ingrained in the kernel that it would be a major undertaking to
increase the maximum value of NBUF, or maybe it would break
device drivers that were written based on that layout, or something
like that.

Like I said, just a guess.
--
Stephen M. Dunn <stephen@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/

Frederico Fonseca wrote:

> After some searches on google, it seems that the value for NBUF in
> these systems is limited to around 450MB.
>
> If the above is correct, is there anyone that knows why this limit
> wasn't increased with 5.0.7?
> Technical explanation appreciated.
>
> If incorrect how do we change it to be above that limit as some of my
> colleagues would like to be able to do it.

The limit remains 450MB.

Buffer cache buffers are allocated out of kernel virtual addresses which
can be "direct mapped". These are addresses in the C0000000-DFFFFFFF
range. Kernel virtual addresses in this range can be converted to
physical addresses by subtracting C0000000; and conversely, physical
addresses below 20000000 can be converted to kernel virtual addresses by
adding C0000000. (Of course there are macros that should be used. You
wanted the technical details...)

The total range in question is 1/2 gigabyte. The actual limit of 450MB
was arbitrarily set to leave some direct-map space for other uses. It
could probably be pushed up to 475MB or something like that, but I
doubt you would find such a small increment helpful.

Why is the direct map important here? HBAs usually need to know the
physical address of a transfer buffer, since the DMA hardware speaks
physical addresses. Converting an virtual address to a physical address
is very cheap for addresses in the direct map. It's expensive for other
addresses, requiring the kernel to walk data structures looking for the
translation. HBA drivers typically use the cheap macros instead of the
expensive data-structure-walking functions; especially since the buffer
cache is designed to always give them a direct-map buffer address.

Expanding beyond the direct map would require one of:

(1) another bounce-buffer scheme where the buffer cache would always
pass direct-map addresses to the HBA driver, then copy the data
elsewhere (as is already done for HBA drivers that do ISA DMA to
addresses < 16MB); or

(2) new protocols between HBA drivers and the buffer cache, so the
buffer cache would know which buffers never to deliver to a
particular HBA. This would also require updated HBA drivers to
take advantage of the new scheme.

>Bela<

On Mon, 25 Aug 2003 20:58:48 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>Hi all,
>
>
>After some searches on google, it seems that the value for NBUF in
>these systems is limited to around 450MB.
>
>If the above is correct, is there anyone that knows why this limit
>wasn't increased with 5.0.7?
>Technical explanation appreciated.
>
>If incorrect how do we change it to be above that limit as some of my
>colleagues would like to be able to do it.
>
>
>Thanks all
>
>
>
>
>Frederico Fonseca
>ema il: frederico_fonseca at syssoft-int.com

Bela and Steve,

Thank you both for your answers.
The tech bit is good enough and does clarify the reasons why.


Thanks.

Frederico Fonseca


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com