lwp_create() on solaris

[kamal]

hello,

Can someone tell me the prototy[e fpr lwp_create on solaris10? I wish
to create a kernel thread from inside a kernel module.

Also, I think it is possible to do the same with timeout() function.
But I would like to know how to do so in such a way that new thread
gets scheduled on another under-utiilized processor in an SMP system.

thanks
-kamal

[Andrew Gabriel]

In article <c70609e9-94a2-4e27...@o3g2000pby.googlegroups.com>,

kamal <kam...@gmail.com> writes:
> hello,
>
> Can someone tell me the prototy[e fpr lwp_create on solaris10? I wish

lwp_create is a private syscall which is used by thr_create(3C) and
pthread_create(3C) for creating threads for user processes. It can't
be used to create threads from/for kernel modules.

> to create a kernel thread from inside a kernel module.

That's done with thread_create:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/disp/thread.c#313

However, you are going to need to know the kernel quite well in order
to use this correctly, and I'm pretty sure it's not a public interface,
meaning it can change at any time.

> Also, I think it is possible to do the same with timeout() function.

timeout() calls you back from a separate thread which is used to call
the all the callbacks (this varies with exact release, as it has been
changed). That thread is not yours. Indeed, if you do any extensive
work in that thread, you'll mess up the subsequent timeout callbacks
for other users of the timeout mechanism.

> But I would like to know how to do so in such a way that new thread
> gets scheduled on another under-utiilized processor in an SMP system.

That happens automatically, providing you haven't done anything to bind
it to specific cpu threads.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

[kamal]

On Jun 4, 1:24 pm, and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
> In article <c70609e9-94a2-4e27-bfb7-f740c69b3...@o3g2000pby.googlegroups.com>,

>         kamal <kama...@gmail.com> writes:
>
> > hello,
>
> >  Can someone tell me the prototy[e fpr lwp_create on solaris10? I wish
>
> lwp_create is a private syscall which is used by thr_create(3C) and
> pthread_create(3C) for creating threads for user processes. It can't
> be used to create threads from/for kernel modules.
>
> > to create a kernel thread from inside a kernel module.
>

> That's done with thread_create:http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/com...
>
thanks. Can you tell me how to ensure that created thread will be
executed in real time at the hghest priority?
If the kernel module that created it is killed, will the thread die
automatically?


thanks
-kamal

[Andrew Gabriel]

In article <d0ef790d-27c9-495a...@st3g2000pbc.googlegroups.com>,

kamal <kam...@gmail.com> writes:
> On Jun 4, 1:24 pm, and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
>> In article <c70609e9-94a2-4e27-bfb7-f740c69b3...@o3g2000pby.googlegroups.com>,
>>         kamal <kama...@gmail.com> writes:
>>
>> > hello,
>>
>> >  Can someone tell me the prototy[e fpr lwp_create on solaris10? I wish
>>
>> lwp_create is a private syscall which is used by thr_create(3C) and
>> pthread_create(3C) for creating threads for user processes. It can't
>> be used to create threads from/for kernel modules.
>>
>> > to create a kernel thread from inside a kernel module.
>>
>> That's done with thread_create:http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/com...
>>
> thanks. Can you tell me how to ensure that created thread will be
> executed in real time at the hghest priority?

You would first have to ensure the RT scheduling class is loaded
into the kernel (easiest way would be to momentarily run something
in the RT class, which will auto-load it). Then assign a RT pri
when creating the thread.

> If the kernel module that created it is killed, will the thread die
> automatically?

Kernel modules can't be killed. The kernel may ask a module to
unload (due to modunload(1M) command, or pressure on kernel memory)
but the module gets to say yes or no. If a module allows itself to
be unloaded whilst there are still threads accessing its code or data,
the kernel will panic/crash. A module would need to keep a record of
the threads it has started, and if it wants to unload, it would need
to ask them to exit and wait for them to do so before allowing itself
to unload. (It wasn't until sometime around Solaris 10 that a method
was provided to do this, so before that, modules that started up new
kernel threads could never unload as there was no safe way for them
to ensure those threads had terminated.)

I would suggest that instead of doing all this, you write a pseudo
driver (and not a STREAMS driver), and that you get the driver to run
a realtime thread by creating a realtime process which calls into
the driver with an ioctl, which will then be a realtime thread
running in your kernel code. You are then using all the standard
public kernel interfaces. I suggest you make sure your driver allows
the process to be killed, and allows itself to be unloaded - this
saves very many reboots during kernel module development, and
provides a clean way to shutdown your thread(s).

This is the way things like nfsd work - a tiny user process calls into
the kernel to create the kernel threads, and all the work is done
in those kernel threads after that, and the user process just hangs
around so it can be killed in order to shutdown those kernel threads.

BTW, why do you want a RT kernel thread? I would have to say that
mostly, the people who think they need to use RT are misguided.


> thanks
> -kamal

[kam...@gmail.com]

[kam...@gmail.com]

On Saturday, June 9, 2012 2:47:56 PM UTC+5:30, Andrew Gabriel wrote:
> In article <d0ef790d-27c9-495a...@st3g2000pbc.googlegroups.com>,
> kamal <kam...@gmail.com> writes:
> > On Jun 4, 1:24 pm, and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
> >> In article <c70609e9-94a2-4e27-bfb7-f740c69b3...@o3g2000pby.googlegroups.com>,
> >>         kamal <kama...@gmail.com> writes:
> >>
> >> > hello,
> >>
> >> >  Can someone tell me the prototy[e fpr lwp_create on solaris10? I wish
> >>
> >> lwp_create is a private syscall which is used by thr_create(3C) and
> >> pthread_create(3C) for creating threads for user processes. It can't
> >> be used to create threads from/for kernel modules.
> >>
> >> > to create a kernel thread from inside a kernel module.
> >>
> >> That's done with thread_create:http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/com...
> >>
> > thanks. Can you tell me how to ensure that created thread will be
> > executed in real time at the hghest priority?
>
> You would first have to ensure the RT scheduling class is loaded
> into the kernel (easiest way would be to momentarily run something
> in the RT class, which will auto-load it). Then assign a RT pri
> when creating the thread.
>

the last parameter to thread_create() is pri. If I set it to 0, does it not ensure that thread will execute as fast as ut can? Or what are the possible values and their meaning?

[snip]

>
> BTW, why do you want a RT kernel thread? I would have to say that
> mostly, the people who think they need to use RT are misguided.
>

The STREAMS driver gets data from h/w via an interrupt and sends it up the stack. The TCP/IP stack on solaris is not as fast as linux and so instead of waiting for it to finish before returning control from the ISR, I would like to split the work into 2 parts, the bottom half is tied to a given processor where interrupt is generated and creates an mblk_t for use by kernel thread which is free to migrate and processes the generated mblk_t as fasr as it can. If the kernel thread is going to be scheduled at a lower priority, the driver will not be able to process data at line rate,

thanks
-kamal