SMP problem with uma_zalloc

[Harti Brandt]

On Mon, 21 Jul 2003, Bosko Milekic wrote:

BM>  Ahhhh.  Given the explanation, the small size of the limits makes a
BM>  lot more sense now.  Previously, the limit probably enforced the
BM>  actual number of cached (pre-allocated) items in the pool.  So, it was
BM>  more than just a "limit," it was a cache size parameter.  That is
BM>  probably why its size was kept relatively small.  In the zone setting,
BM>  the limit can easily be made larger or removed altogether (if there is
BM>  no danger of that structure consuming all of kernel memory).

No, there isn't. VCCs are usually limited by the interface card to a couple
of thousand.

BM>> How do you think about adding a paragraph for uma_zone_set_max to the man
BM>> page?:
BM>>
BM>> An upper limit of items in the zone can be specified with a call to
BM>> uma_zone_set_max. This limits the total number of items which includes:
BM>> allocated items, free items and free items in the per-cpu caches. On
BM>> systems with more than one CPU it may not be possible to allocate the
BM>> specified number of items, because all of the remaining free items may
BM>> be in the caches of the other CPUs when the limit is hit.
BM>
BM>  Given that it has obviously led to confusion, this sort of change to
BM>  the man page would be encouraging.
BM>
BM>  Perhaps you would also ammend to it the purpose of uma_zone_set_max(),
BM>  as it currently stands:
BM>
BM>  "The purpose of uma_zone_set_max() is to limit the maximum
BM>  amount of memory that the system can dedicate toward the zone
BM>  specified by the 'zone' argument." <insert your text from above here>
BM>
BM>  Would you like to commit the change?

Ok, I'll commit it.

Regards,
harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org