|
Description
|
We've seen a number of workloads which would benefit from a wider selection
of large kmem caches. A proposal recently discussed is to create a new
selection of pagesize-multiple caches. The idea is that larger caches
would benefit a variety of newer workloads in which large allocations
have become more prevalent. Roch put it this way:
"At the same time, do we agree on a need an increase to
KMEM_MAXBUF. I've hit this limit in CIFS and comstar lately
where each project had to go and implement caches up to
128K. On that topic, I am not sure if we should simply
support a greater KMEM_MAXBUF or use a second level
kmem_alloc_table2[] and KMEM_ALIGN_SHIFT2 to deal with values
greater than X. We would then reduce the cache footprint of
kmem_alloc_table but increae the icache footprint of
kmem_alloc()."
A possible downside is that we'd wind up wiring down some of these
buffers, even on small systems. This might be a place where using
a more dynamic scheme to arrive at the largest cache size would be
appropriate, perhaps based on total system memory. While
KMEM_MAXBUF needs to be a #define, it might be the case that
KMEM_MAXBUF2 could be a variable, instead of a #define.
I support this proposal, and I'm filing this RFE to request
that it be investigated and, hopefully, implemented.
It's also noteworthy that this would be a good chance to clean
up the STREAMS dblk caches as well.
|