From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Date: Thu, 28 Jul 2005 09:33:21 +0200 [thread overview]
Message-ID: <20050728073321.GB20055@elte.hu> (raw)
In-Reply-To: <1122475591.29823.76.camel@localhost.localdomain>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > a fair number of apps assume that there's _at least_ 100 levels of
> > priorities. The moment you have a custom kernel that offers more than
> > 100 priorities, there will be apps that assume that there are more than
> > 100 priority levels, and will break if there are less.
>
> That's not the same. The apps on my computer right now should not
> assume that I have 100 priorities. Since I'm free to work with any
> kernel that I want. The customers that ask for a custom kernel are
> also writing custom apps for a specific product. Things can be
> assumed more since the apps are not generic tools that are running on
> desktops. In fact, some of these apps require special hardware to
> work (at least a driver to imitate the hardware).
what i mean is that once there's such a .config option in the generic
kernel, the cat is out of the bag and there's no way back. In other
words, increasing the number of priorities is an irreversible change, in
terms of binary compatibility.
there's absolutely no problem with tweaking your kernel for special
purposes, and i support all the patches to make it easier (as long as
there's no cost to the kernel - and there's no such cost so far). But
whenever some change in the generic kernel has a user-visible effect,
especially one that is pretty much irreversible, we have to be very
careful.
(I think in the longer term we might want to do something more clever
than a blanket increase of the priority levels, we could e.g. put a
mapping layer between user priorities and kernel priorities, and in fact
we could make 'user-visible' RT priorities a bit more structured, like a
hierarchy of levels - while keeping the in-kernel priorities a fast &
flat thing (which could have more than 100 levels - but that would not
be visible externally). There's some demand for that, but we'll have to
wait and see for real demand and real code to crystalise out.)
Ingo
next prev parent reply other threads:[~2005-07-28 7:33 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-27 14:13 Steven Rostedt
2005-07-27 14:17 ` Ingo Molnar
2005-07-27 14:26 ` Steven Rostedt
2005-07-27 14:33 ` Ingo Molnar
2005-07-27 14:47 ` [PATCH] safty check of MAX_RT_PRIO >= MAX_USER_RT_PRIO Steven Rostedt
2005-07-27 15:05 ` Steven Rostedt
2005-07-27 18:52 ` Ingo Molnar
2005-07-27 14:53 ` [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable Esben Nielsen
2005-07-27 15:02 ` Steven Rostedt
2005-07-27 16:09 ` K.R. Foley
2005-07-27 17:01 ` Esben Nielsen
2005-07-27 17:25 ` Steven Rostedt
2005-07-27 21:32 ` Esben Nielsen
2005-07-28 12:17 ` Steven Rostedt
2005-07-28 7:22 ` Ingo Molnar
2005-07-28 11:53 ` Steven Rostedt
2005-07-27 17:42 ` K.R. Foley
2005-07-28 9:59 ` Esben Nielsen
2005-07-27 14:28 ` Steven Rostedt
2005-07-27 14:38 ` Ingo Molnar
2005-07-27 14:46 ` Steven Rostedt
2005-07-28 7:33 ` Ingo Molnar [this message]
2005-07-28 1:42 ` Matt Mackall
2005-07-28 1:00 ` Daniel Walker
2005-07-28 1:20 ` Lee Revell
2005-07-28 1:26 ` Steven Rostedt
2005-07-28 1:25 ` Steven Rostedt
2005-07-28 3:06 ` Steven Rostedt
2005-07-28 3:32 ` Steven Rostedt
2005-07-28 3:45 ` Steven Rostedt
2005-07-28 3:51 ` Nick Piggin
2005-07-28 11:43 ` [PATCH] speed up on find_first_bit for i386 (let compiler do the work) Steven Rostedt
2005-07-28 12:45 ` Steven Rostedt
2005-07-28 15:31 ` Linus Torvalds
2005-07-28 15:30 ` Linus Torvalds
2005-07-28 15:47 ` Steven Rostedt
2005-07-28 16:34 ` Maciej W. Rozycki
2005-07-28 16:57 ` Steven Rostedt
2005-07-28 17:25 ` Linus Torvalds
2005-07-29 10:03 ` David Woodhouse
2005-07-29 14:41 ` Maciej W. Rozycki
2005-07-29 16:23 ` Linus Torvalds
2005-07-29 14:39 ` Maciej W. Rozycki
2005-07-29 16:29 ` Linus Torvalds
2005-07-29 17:14 ` Maciej W. Rozycki
2005-07-28 17:17 ` Linus Torvalds
2005-07-29 15:09 ` Maciej W. Rozycki
2005-07-28 18:25 ` Steven Rostedt
2005-07-28 18:56 ` Linus Torvalds
2005-07-28 17:52 ` Mitchell Blank Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050728073321.GB20055@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®