On Wed, Dec 14, 2016 at 03:52:32PM +1000, David Gwynne wrote:
> > Wouldn't it make sense to use atomic operations to keep track of the
> > amount of memory that was allocated?
>
> the mtx may be slow, but it is a slow path id like to keep simple.
Is allocate and free of mbuf clusters in the slow path? I would
expect that it has to be done for every packet. An atomic operation
would not solve the slowdown in the fast path, perhaps a multi-cpu
counter?
> > Long run I suppose we want to drop nmbclust and let users tune the
> > total amount of memory available for clusters and set the initial
> > amount to a percentage of physical memory?
>
> i do want to move to specifying memory in terms of bytes instead of 2k
> clusters.
That might be better. But leave it as it is for now. Percentage
of physical memory is bad as we have architectures that cannot do
DMA everywhere.
> how much should be available by default is a complicated issue.
Yes. Maybe we have to reconsier the default. We had it per cluster
size before, now the limit is for all clusters.
> >> void
> >> mbcpuinit()
> >> {
> >> + int i;
> >> +
> >> mbstat = counters_alloc_ncpus(mbstat, MBSTAT_COUNT, M_DEVBUF);
> >> +
> >> + pool_cache_init(&mbpool);
> >> + pool_cache_init(&mtagpool);
> >> +
> >> + for (i = 0; i < nitems(mclsizes); i++)
> >> + pool_cache_init(&mclpools[i]);
> >> }
Is the pool cache related to the global mbuf limit?
Apart from the problem that I don't know wether the mutex kills
performance, the diff looks good.
bluhm
