Messages in this thread | | | Date | Mon, 7 Jan 2008 16:53:18 +0100 | From | "Remy Bohmer" <> | Subject | Re: [PATCH] kthread: always create the kernel threads with normal priority |
| |
Hello Michal,
> > Maybe we can find a way to use a similar mechanism as I used in my > > patchset for the priorities of the remaining kthreads. > > I do not like the way of forcing userland to change the priorities, > > because that would require a userland with the chrt tool installed, > > and that is not that practical for embedded systems (in which there > > could be cases that there is no userland at all, or the init-process > > is the whole embedded application). In that case an option to do it on > > the kernel commandline is more practical. > > > > I propose this kernel cmd-line option: > > kthread_pmap=somethread:50,otherthread:12,34 > > I see. kthreadd would look up the priority for itself and > kthread_create would consult the map for all other kernel threads. > That should work. > Your sirq_pmap would not be needed anymore, as kthread_pmap could be > used for softirq threads too, right?
That is correct. The soft-irqs are just ordinary kernel-threads, but irq_pmap is still needed, to set the priority of a certain interrupt handler. In this case it also possible to set the prio of the IRQ-kthreads as well as the prio of a certain interrupt handler. This might give some conflicts, and I have to check how to resolve these.
Kind Regards,
Remy
2008/1/7, Michal Schmidt <mschmidt@redhat.com>: > On Mon, 7 Jan 2008 12:22:51 +0100 > "Remy Bohmer" <linux@bohmer.net> wrote: > > > Hello Michal and Andrew, > > > > > Let's not make the decision for the user. Just allow the > > > administrator to change kthreadd's priority safely if he chooses to > > > do it. Ensure that the kernel threads are created with the usual > > > nice level even if kthreadd's priority is changed from the default. > > > > Last year, I posted a patchset (that was meant for Preempt-RT at that > > time) to be able to prioritise the interrupt-handler-threads (which > > are kthreads) and softirq-threads from the kernel commandline. See > > http://lkml.org/lkml/2007/12/19/208 > > > > Maybe we can find a way to use a similar mechanism as I used in my > > patchset for the priorities of the remaining kthreads. > > I do not like the way of forcing userland to change the priorities, > > because that would require a userland with the chrt tool installed, > > and that is not that practical for embedded systems (in which there > > could be cases that there is no userland at all, or the init-process > > is the whole embedded application). In that case an option to do it on > > the kernel commandline is more practical. > > > > I propose this kernel cmd-line option: > > kthread_pmap=somethread:50,otherthread:12,34 > > I see. kthreadd would look up the priority for itself and > kthread_create would consult the map for all other kernel threads. > That should work. > Your sirq_pmap would not be needed anymore, as kthread_pmap could be > used for softirq threads too, right? > > Michal >
| |