YAMAMT Takashi wrote:
>Sun, Jun 11, 2006 at 02:45:45PM +0900, YAMAMT Takashi wrote:
>
which includes:
1. implement solaris-like vmem.

>Could you elaborate a bit what this is and why you are changing things?
>I have no idea what solaris "vmem" is.
>>
>Martin
>
>
for "what's vmem", see:

as i wrote in the previous mail, my primary purpose at this point is
to make amap use kernel_map rather than kmem_map.
(the latter is more restricted and there's no point for amap to use it.)

for long term, i'd like to replace extent(9) and malloc(9),
but my implementation is still far from it.

YAMAMT Takashi

The Solaris kernel memory allocator is *very* robust, and quite
efficient. I used it to replace a busted allocator in thin-client, and
much joy was held at suddenly new-found memory that gained by an
efficient allocator. (Efficient in both space and time.)

the other hand, I've not looked seriously at our versions. Is there a
"need" to replace extent and malloc? I think extent is still needed at
least, because I don't think the Solaris vmem system really addresses
this need (at least Solaris 9 didn't -- they have separate code built on
top of kmem_alloc for that.)

The other thing is that the cost of free/alloc with a cache allocation
goes *way* down, but it requires more intelligence on the part of
drivers. (You have to specify a size with kmem_free().)

Finally, is there a reason that you couldn't make KM_NSLEEP style
allocations work from interrupt context ala the Solaris kmem_alloc
(perhaps by going to a different allocation pool?)

I should probably look at your source in more detail. What would be
really nice would be to expose kmem_cache_alloc() - like implementation.

Chapman Flack wrote:
YAMAMT Takashi wrote:
>for "what's vmem", see:
>
>
Cool beans. Did Sun apply for patents? -Chap
I'm not aware of any. This allocator has been used in other free S' --
including Linux I believe.

YAMAMT Takashi wrote:
>the other hand, I've not looked seriously at our versions. Is there a
>"need" to replace extent and malloc?
>
>
i think it's an improvement because:
- extent is linear-search based.
- it isn't trivial to extend malloc to use backends other than
kmem_map.
- malloc is not very space efficient.
- for some workloads, malloc's "permanent allocation" policy
is horrible.

of course, we can just improve extent and malloc instead.
(in that case, i don't volunteer at this point, tho. :)


>I think extent is still needed at
>least, because I don't think the Solaris vmem system really addresses
>this need (at least Solaris 9 didn't -- they have separate code built on
>top of kmem_alloc for that.)
>
>
what's the particular feature of extent, which can't be done with vmem,
in your mind?
"fragment" case of extent_free?

The ability to match particular alignment constraints, for one. This can
be implemented on top of kmem_alloc of course, but may be less efficient
in such a case.

Most of my experience is not with vmem_alloc, per se, but rather with
kmem_cache_alloc and the slab allocator.


>Finally, is there a reason that you couldn't make KM_NSLEEP style
>allocations work from interrupt context ala the Solaris kmem_alloc
>(perhaps by going to a different allocation pool?)
>
>
this implementation is not intrsafe because it's backed by kernel_map,
which is not intrsafe.

i chose kernel_map because i thought that it was suitable for the common cases.
it's trivial to provide another one, say, kmem_alloc_intrsafe(),
which is backed by kmem_map.

, since you're emulating Solaris, have it specified by a flag.

although i don't know solaris internals much, i guess it doesn't distinguish
intrsafe/nointr allocations as we does. right?

It does. Look at KM_NSLEEP in the flags argument. KM_SLEEP allocations
are not interrupt safe, KM_NSLEEP allocations never sleep, and hence
are interrupt safe (but may fail).

>I should probably look at your source in more detail. What would be
>really nice would be to expose kmem_cache_alloc() - like implementation.
>
>
iirc, there are no fundamental differences between kmem_cache_alloc
and our pool_cache. it's easier to implement per-cpu things for pool_cache.

Probably true. I'm not even aware of pool_cache. There's a lot of NetBSD
internals I still need to learn about.

kmem_alloc (not vmem_alloc, which is lower layer) is implemented on top
of kmem_caches that are size oriented. So, assuming that you pick good
sizes for the slab allocator, you get very little internal
fragmentation, and pretty much non-existent external fragmentation.
-- Garrett
YAMAMT Takashi

YAMAMT Takashi wrote:
I think extent is still needed at
least, because I don't think the Solaris vmem system really addresses
this need (at least Solaris 9 didn't -- they have separate code built on
top of kmem_alloc for that.)

what's the particular feature of extent, which can't be done with vmem,
in your mind?
"fragment" case of extent_free?


>The ability to match particular alignment constraints, for one. This can
>be implemented on top of kmem_alloc of course, but may be less efficient
>in such a case.
>
>
solaris vmem_xalloc has constraint arguments, including alignment,
doesn't it? (no idea about its efficiency or implementation, tho.)

Underlying vmem probably does. I've not used it before. My experience is
more with the layer above, at kmem_cache_alloc and friends. :-) If vmem
will do it, then great!

although i don't know solaris internals much, i guess it doesn't distinguish
intrsafe/nointr allocations as we does. right?


>It does. Look at KM_NSLEEP in the flags argument. KM_SLEEP allocations
>are not interrupt safe, KM_NSLEEP allocations never sleep, and hence
>are interrupt safe (but may fail).
>
>
even if you never sleep, our kernel_map is not interrupt safe.

Yes, but the KM_NSLEEP flag could be a hint to use an interrupt safe map.
-- Garrett

YAMAMT Takashi <yamt (AT) mwd (DOT) biglobe.ne.jpwrites:

solaris vmem_xalloc has constraint arguments, including alignment,
doesn't it? (no idea about its efficiency or implementation, tho.)

The paper linked to earlier in this thread says so:

} We also provide a vmem_xalloc() interface that can specify common
} allocation constraints: alignment, phase (offset from the
} alignment), address range, and boundary-crossing restrictions
} (e.g. don't cross a page boundary).

Now, implementation well, there's the Solaris source.

YAMAMT Takashi wrote:
even if you never sleep, our kernel_map is not interrupt safe.


>Yes, but the KM_NSLEEP flag could be a hint to use an interrupt safe map.
>
>
i don't think it's a good idea because it implies to make kmem_free complicate.
ie. it has to figure out which map the region should be freed back to.

YAMAMT Takashi

Good point; I didn't consider that. I should probably look more closely
at our implementation. just STFU, I guess. Given current time
constraints, I'll probably do the latter. :-)