[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080107141014.3815fcca@brian.englab.brq.redhat.com>
Date: Mon, 7 Jan 2008 14:10:14 +0100
From: Michal Schmidt <mschmidt@...hat.com>
To: "Remy Bohmer" <linux@...mer.net>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Jon Masters" <jcm@...hat.com>,
"Satoru Takeuchi" <takeuchi_satoru@...fujitsu.com>,
"Steven Rostedt" <rostedt@...dmis.org>
Subject: Re: [PATCH] kthread: always create the kernel threads with normal
priority
On Mon, 7 Jan 2008 12:22:51 +0100
"Remy Bohmer" <linux@...mer.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists