> > Jeff , (current included because it may be an interesting answer) > > > As you know I'm using UMA to allocate threads and cache them. > The 'constructor methods allow me to allocated threads that have been > pre-set up with thread stacks and other special items. > > > When they are being cached they still have their stacks etc. attached to > them. These are only splitt off when the UMA decides to stop caching an > item and actualy return it's memory to the system. > In this regard the UMA allocator is not a memory alocator but a 'complex > object allocator'... Very cool. > > Now my question.. > > I ant to allocate proc structures the same way... > in other words, I want a cached proc structure to already have a thread > attached to it and a stack attached to the thread.. > Is it legal for teh init function which is called by UMA to in turn > call UMA to allocate a sub element.. > > so if I do uma_zalloc(proc args) > that in turn should do a uma_zalloc(thread args). > would this work? is it legal?
No locks are held when doing init ctor or fini. The zone and possibly per cpu queue lock is held while doing the dtor though. So it is safe as long as you don't cause a recursive allocation in the same zone. In short, what you want to do is perfectly reasonable. > > I need to allocate extra threads independantly of processes, but I could > work it so that freed process structures always had a single thread left > on them, which would save on allocations.. > In the future I need to do teh same for KSEs and KSEGRPS. sp having > UMA cache pre-constructed complex items made up of groups of separatly > UMA-allocated objects would be a great saving.. > > the question is.. will it work? can I call UMA from withing a UMA > constructor? > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
