On Mon, 7 Jan 2008 12:22:51 +0100 "Remy Bohmer" <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
