Frank Hofmann - Solaris Sustaining wrote:
>>I'm not sure if this is the right venue for this question. Does anybody know
>>off-hand if kernel stacks are pageable? Is it safe to create a condition
>>variable on a kernel stack?
>>_______________________________________________
>>opensolaris-code mailing list
>>[email protected]
>>https://opensolaris.org:444/mailman/listinfo/opensolaris-code
>
>
> Hi Robert,
>
> Even though kernel stacks are unpageable, it's unsafe to create
> a condition variable on a kernel stack. How do you guarantee that
> this piece of callflow-local data will not be overwritten/reused
> in a later instantiation of a different call sequence using the
> same stack ?
Yes, I can kmem_alloc the condition variable. However, I'm only using it for
the duration of a thread wait. In this case, it's in the read entry point of a
character device. I don't want to incur the cost of calling a sub allocator,
both in terms of processor time and memory fragmentation for something this
trivial. I know that after the wait, the condition variable will not be used
again.
> You could of course consider doing something like thread_create(),
> and then in essence have a (persistent) 'main()'-like function
> running that'll stay around 'forever', together with its associated
> local data. I.e. if you never unwind the call sequence by returning
> to the bottommost function then the unwound part of the stack becomes
> "permanent data" - which isn't equivalent to global data but can
> technically be made so by providing a way to find its location
> (i.e. a pointer to it).
>
> Is that good programming practice ? Definitely not. What you want
> to do is to elevate the scope of local variables to global. Yes,
> the C language allows you to do such things through the backdoor
> but forcing this calls for later trouble.
> And it's in no way simpler than doing a kmem_alloc()/cv_init().
I will be servicing read requests from multiple threads simultaneously.
Therefore, one condition variable will not do, unless I want to cause a
thundering herd wakeup. I would rather wake up one thread than do a broadcast.
Yes, I could cache allocate the condition variable, but again, that seems rather
heavy handed for something I need for a short period of time.
> I.e. why do you want to what amounts to:
>
> func()
> {
> kcondvar_t mycv;
> cv_init(&myvc, NULL, CV_DRIVER, NULL);
>
> for(;;)
> main_handler_func(&mycv);
> }
Precisely.
> instead of:
>
> func()
> {
> kcondvar_t *mycv = kmem_alloc(sizeof(kcondvar_t), KM_SLEEP);
> cv_init(myvc, NULL, CV_DRIVER, NULL);
>
> for(;;)
> main_handler_func(mycv);
> }
>
> What's the advantage ? You don't save nothing. Typing 30 characters,
> maybe. For what ? Purely academic interest ?
You save multiple calls to a sub-allocator. In my case, there would need to be
a kmem_alloc and a kmem_free. Yes, as I mentioned above, I could cache allocate
the condition variable, but why bother when I can simply init and destroy it
before and after use on the call stack?
> Best Regards,
> FrankH.
Likewise :-)
_______________________________________________
opensolaris-code mailing list
[email protected]
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
