On Sun, 15 Apr 2007, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
I took a brief look at it. Have you tested priority inheritance?
yeah, you are right, it's broken at the moment, i'll fix it. But the
good news is that i think PI could become cleaner via scheduling
classes
On Wed, 18 Apr 2007, Ingo Molnar wrote:
* Christian Hesse [EMAIL PROTECTED] wrote:
Hi Ingo and all,
On Friday 13 April 2007, Ingo Molnar wrote:
as usual, any sort of feedback, bugreports, fixes and suggestions are
more than welcome,
I just gave CFS a try on my system. From a user's
On Sat, 10 Feb 2007, Andrew Burgess wrote:
I have terrible news: 2.6.20-rt5 does not boot at all on a couple
machines I was brave enough to try -- a [EMAIL PROTECTED] SMP/HT desktop, and a
Core2 Duo [EMAIL PROTECTED] laptop.
Ditto for me on an ASUS AMD64 x2, just hangs, I have no
serial
On Tue, 10 Apr 2007, Jan Engelhardt wrote:
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
ArcNet is old. Almost nobody is using it anymore. I used it at my former
job, since we used it as control network. A lot of companies still does
quitely, but not in combination
On Wed, 11 Apr 2007, Jan Engelhardt wrote:
On Apr 11 2007 10:30, Esben Nielsen wrote:
On Tue, 10 Apr 2007, Jan Engelhardt wrote:
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
ArcNet is old. Almost nobody is using it anymore. I used it at my
former job, since we used
On Fri, 13 Apr 2007, Ingo Molnar wrote:
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
i'm pleased to announce the first release of the Modular Scheduler Core
and Completely Fair Scheduler [CFS] patchset:
On Wed, 1 Aug 2007, Daniel Walker wrote:
On Wed, 2007-08-01 at 07:59 -0400, Gregory Haskins wrote:
On Tue, 2007-07-31 at 20:52 -0700, Daniel Walker wrote:
Here's a simpler version .. uses the plist data structure instead of the
100 queues, which makes for a cleaner patch ..
Hi Daniel,
I looked at the PI-code to see what priority the task (old_owner below)
would end up with when it released a lock. From rt.c:
prio = mutex_getprio(old_owner);
if (new_owner !plist_empty(new_owner-pi_waiters)) {
w = plist_entry(new_owner-pi_waiters, struct
, Perez-Gonzalez, Inaky wrote:
From: Esben Nielsen [mailto:[EMAIL PROTECTED]
On 12 Apr 2005, Daniel Walker wrote:
At least, both mutexes will need to use the same API to raise and
lower
priorities.
You basicly need 3 priorities:
1) Actual: task-prio
2) Base prio with no RT locks
On 12 Apr 2005, Daniel Walker wrote:
I just wanted to discuss the problem a little more. From all the
conversations that I've had it seem that everyone is worried about
having PI in Fusyn, and PI in the RT mutex.
It seems like these two locks are going to interact on a very limited
Hi, I am trying to compile and run UM-Linux with PREEMPT_REALTIME. I
managed to get it to compile but it wont start - it simply stops somewhere
in start_kernel() :-(
Have anyone else looked at it?
It doesn't sound like it makes much sense to have PREEMPT_REALTIME for UML
but I thought it was a
Well, I keep trying a little bit more. In the mean while you can get some
of the stuff I needed to change to at least get it to compile:
One of the problems was use of direct architecture specific semaphores
(which doesn't work under PREEMPT_REALTIME) and in places where a quick
(maybe too quick)
On Tue, 8 Feb 2005, Jeff Dike wrote:
[EMAIL PROTECTED] said:
Jeff, any objections against adding this change to UML at some point?
No, not at all. I just need to understand what CONFIG_PREEMPT requires of
UML.
Ingo can probably tell you in much more detail. My problem when I tried to
On Tue, 8 Feb 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
Now I don't really know who I am responding to. But both up()s now
changed to complete()s are in something looking very much like an
interrupt handler. But again, as I said, I didn't analyze the code
On Fri, 15 Jul 2005, Daniel Walker wrote:
On Fri, 2005-07-15 at 12:23 +0200, Ingo Molnar wrote:
* Daniel Walker [EMAIL PROTECTED] wrote:
PI is always good, cause it allows the tracking of what is high
priority , and what is not .
that's just plain wrong. PI might be good if one
On Thu, 14 Jul 2005, Christoph Hellwig wrote:
On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
This reminds me of Documentation/stable_api_nonsense.txt . That no one
should really be dependent on a particular kernel API doing a particular
thing. The kernel is play dough for
On Wed, 27 Jul 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Perfectly understood. I've had two customers ask me to increase the
priorities for them, but those where custom kernels, and a config
option wasn't necessary. But since I've had customers asking, I
On Wed, 27 Jul 2005, K.R. Foley wrote:
Esben Nielsen wrote:
On Wed, 27 Jul 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Perfectly understood. I've had two customers ask me to increase the
priorities for them, but those where custom kernels, and a config
On Wed, 27 Jul 2005, Steven Rostedt wrote:
On Wed, 2005-07-27 at 19:01 +0200, Esben Nielsen wrote:
What for? Why can't you use FIFO at the same priorities for some of your
tasks? I pretty much quess you have a very few tasks which have some high
requirements. The rest of you RT task
On Wed, 27 Jul 2005, K.R. Foley wrote:
Esben Nielsen wrote:
[...]
All of the RT priorities that we have are not absolutely necessary. As I
think Steven pointed out in another email, it is nice though to be able
to priortize tasks using large jumps in priorities and then being able
On Fri, 18 Mar 2005, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] How about something like:
void
rcu_read_lock(void)
{
preempt_disable();
if (current-rcu_read_lock_nesting++ == 0) {
On Fri, 18 Mar 2005, Ingo Molnar wrote:
* Bill Huey [EMAIL PROTECTED] wrote:
I'd like to note another problem. Mingo's current implementation of
rt_mutex (super mutex for all blocking synchronization) is still
missing reader counts and something like that would have to be
On Fri, 18 Mar 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
Why can should there only be one RCU-reader per CPU at each given
instance? Even on a real-time UP system it would be very helpfull to
have RCU areas to be enterable by several tasks as once. It would
On Sun, 20 Mar 2005, Paul E. McKenney wrote:
On Sun, Mar 20, 2005 at 02:29:17PM +0100, Esben Nielsen wrote:
On Fri, 18 Mar 2005, Ingo Molnar wrote:
[...]
I think it can be deterministic (on the long timescale of memory
management)
anyway: Boost any non-RT task entering an RCU
On Mon, 21 Mar 2005, Paul E. McKenney wrote:
On Mon, Mar 21, 2005 at 12:23:22AM +0100, Esben Nielsen wrote:
[...]
Well, I was actually thinking of an API like
preempt_by_nonrt_disable()
preempt_by_nonrt_enable()
working like the old preempt_disable()/preempt_enable() but still
On Tue, 22 Mar 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
On the other hand with a rw-lock being unlimited - and thus do not
keep track of it readers - the readers can't be boosted by the writer.
Then you are back to square 1: The grace period can take a very
On Tue, 22 Mar 2005, Bill Huey wrote:
On Fri, Mar 18, 2005 at 05:55:44PM +0100, Esben Nielsen wrote:
On Fri, 18 Mar 2005, Ingo Molnar wrote:
i really have no intention to allow multiple readers for rt-mutexes. We
got away with that so far, and i'd like to keep it so. Imagine 100
On Tue, 22 Mar 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
+static inline void rcu_read_lock(void)
+{
+ preempt_disable();
+ __get_cpu_var(rcu_data).active_readers++;
+ preempt_enable();
+}
this is buggy. Nothing guarantees that we'll do
On Tue, 22 Mar 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
+static inline void rcu_read_lock(void)
+{
+ preempt_disable();
+ __get_cpu_var(rcu_data).active_readers++;
+ preempt_enable();
+}
this is buggy. Nothing
On Tue, 22 Mar 2005, Paul E. McKenney wrote:
On Tue, Mar 22, 2005 at 09:55:26AM +0100, Esben Nielsen wrote:
On Mon, 21 Mar 2005, Paul E. McKenney wrote:
[ . . . ]
On Mon, Mar 21, 2005 at 12:23:22AM +0100, Esben Nielsen wrote:
This is in some ways similar to the K42 approach to RCU
is the grabber, and the
grabber's priority is = the owner's priority.
there's another approach that could solve this problem: let the
scheduler sort it all out. Esben Nielsen had this suggestion a couple of
months ago - i didnt follow it because i thought that technique would
create too
On Wed, 30 Mar 2005, Steven Rostedt wrote:
[...]
Heck, I'll make it bloat city till I get it working, and then tone it
down a little :-) And maybe later we can have a better solution for the
BKL.
What about removing it alltogether?
Seriously, how much work would it be to simply remove
On Thu, 31 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Well, here it finally is. There's still things I don't like about it.
But it seems to work, and that's the important part.
I had to reluctantly add two items to the task_struct. I was hoping
to
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other
On Mon, 4 Apr 2005, Zwane Mwaikambo wrote:
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
On Tue, 5 Apr 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
Now the question is, who will fix it? Preferably the maintainers, but I
don't know how much of a priority this is to them. I don't have the time
now to look at this and understand enough about the code
As I read the code the driver task (A) should _not_ be removed from the
runqueue. It has to be waken up to call schedule_timeout() such it gets
back on the runqueue after 10 ms. If it is taken out of the runqueue at
line 76 it will stay off the runqueue forever in the TASK_UNINTERRUBTIBLE
state!
On 2 Feb 2005, Kevin Hilman wrote:
While testing an older driver on an -RT kernel (currently using
-V0.7.37-03), I noticed something strange.
The driver was triggering a sleeping function called from invalid
context BUG(). It was coming from a case where the driver was doing
a
On Wed, 24 Aug 2005, Jens Axboe wrote:
On Wed, Aug 24 2005, Lee Revell wrote:
Just found this in dmesg.
BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229
caller is ___down_mutex+0xe9/0x1a0
[c029c1f9] schedule+0x59/0xf0 (8)
[c029ced9] ___down_mutex+0xe9/0x1a0 (28)
On Fri, 26 Aug 2005, Matt Mackall wrote:
On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote:
Ingo Molnar wrote:
i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
as the name already
On Wed, 27 Jul 2005, Matt Porter wrote:
On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
Kumar, I thought that we had some volunteers to take care of some of
those. I know that I still care about
I finally succeeded to get cg-clone to work on
linux/kernel/git/torvalds/linux-2.6.git
I can see the 2.6.13-rc4 is in there and can use cg-diff to see the
difference between the current tree and 2.6.13-rc4.
But how to I extract the 2.6.13-rc4 source from the tree?
Or even more complicated: I
whether lp-next_tx already had an
allocated buffer, and if so, it returns NETDEV_TX_BUSY. This prevents
buffers from dissapearing under heavy traffic.
This patch seems to work fine on my arcnet network, and I also sent it to
the person (Esben Nielsen [EMAIL PROTECTED]) who made some arcnet patches
On Tue, 6 Sep 2005, Jesper Juhl wrote:
On 9/6/05, Budde, Marco [EMAIL PROTECTED] wrote:
Hi,
for one of our customers I have to port a Windows driver to
Linux. Large parts of the driver's backend code consists of
C++.
How can I compile this code with kbuild? The C++ support
(I
On Tue, 6 Sep 2005 [EMAIL PROTECTED] wrote:
On Wed, 07 Sep 2005 00:20:11 +0200, Esben Nielsen said:
Which is too bad. You can do stuff much more elegant, effectively and
safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
it up to the user to make sure the type-casts
On Wed, 7 Sep 2005 [EMAIL PROTECTED] wrote:
On Wed, 07 Sep 2005 11:13:24 +0200, Budde, Marco said:
E.g. in my case the Windows source code has got more than 10 MB.
Nobody will convert such an amount of code from C++ to C.
This would take years.
Do you have any *serious* intent to drop
On Wed, 7 Sep 2005 [EMAIL PROTECTED] wrote:
On Wed, 07 Sep 2005 11:21:42 +0200, Esben Nielsen said:
I use a RTOS written in plain C but where you can easily use C++ in kernel
space (there is no user-space :-). We use gcc by the way.
This isn't RTOS, in case you haven't noticed
On Thu, 16 Nov 2006, Daniel Walker wrote:
On Thu, 2006-11-16 at 16:35 +0100, Ingo Molnar wrote:
-rt0 is a rebase of -rt to 2.6.19-rc6, with lots of updates and fixes
included. It includes the latest -hrt-dynticks tree and more.
Does the zero carry and meaning or did you just decide start
On Wed, 16 Jan 2008, Steven Rostedt wrote:
On Wed, 16 Jan 2008, Steven Rostedt wrote:
We modified mcount now, and it is derived from an objdump of glibc. So
this is most definitely a derived work from glibc. But glibc is licensed
as LGPL, which IIRC allows for non GPL to link to it.
I
On Mon, 21 Jan 2008, Steven Rostedt wrote:
On Mon, 21 Jan 2008, Esben Nielsen wrote:
Please, tell what in the license forbids me to make a global replacement
EXPORT_SYMBOL_GPL - EXPORT_SYMBOL and distribute the result?
If you want to distribute that code, the authors of that said code
may
Hi,
I can not get my com20020 pcmcia driver to work as a module under 2.6.20.
There is the build problem:
MODPOST 30 modules
WARNING: com20020_found [drivers/net/pcmcia/com20020_cs.ko] undefined!
WARNING: com20020_check [drivers/net/pcmcia/com20020_cs.ko] undefined!
The solution:
Always export
On Wed, 7 Feb 2007, Randy Dunlap wrote:
Esben Nielsen wrote:
Hi,
I can not get my com20020 pcmcia driver to work as a module under 2.6.20.
There is the build problem:
Please send me your .config file. I can't seem to reproduce this.
The relevant parts:
...
CONFIG_ARCNET_COM20020=m
On Mon, 7 May 2007, Johannes Stezenbach wrote:
On Mon, May 07, 2007, Linus Torvalds wrote:
On Mon, 7 May 2007, Esben Nielsen wrote:
What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I
can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find
On Tue, 8 May 2007, Peter Williams wrote:
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping
On Tue, 8 May 2007, Johannes Stezenbach wrote:
On Tue, May 08, 2007, Esben Nielsen wrote:
This is contrary to C99 standeard annex H2.2
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf):
An implementation that defines signed integer types as also being modulo
need
not detect
On Thu, 10 May 2007, Li Yu wrote:
Hi, Steven.
Nice to meet you again.
I have read the rt-mutex-design.txt that you wrote. That is excellent
description of rt_mutex. But I have a question for rt_mutex.
As you said:
Now since mutexes can be defined by user-land applications, we don't
On Fri, 11 May 2007, Peter Zijlstra wrote:
I was toying with a scalable rw_mutex and found that it gives ~10% reduction in
system time on ebizzy runs (without the MADV_FREE patch).
You break priority enheritance on user space futexes! :-(
The problems is that the futex waiter have to take
On Sat, 12 May 2007, Peter Zijlstra wrote:
On Sat, 2007-05-12 at 11:27 +0200, Esben Nielsen wrote:
On Fri, 11 May 2007, Peter Zijlstra wrote:
I was toying with a scalable rw_mutex and found that it gives ~10% reduction in
system time on ebizzy runs (without the MADV_FREE patch).
You
On Sat, 12 May 2007, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
I notice that the rwsems used now isn't priority inversion safe (thus
destroying the perpose of having PI futexes). We thus already have a
bug in the mainline.
you see everything in black and white, ignoring
On Sat, 12 May 2007, Eric Dumazet wrote:
Esben Nielsen a écrit :
On Sat, 12 May 2007, Peter Zijlstra wrote:
On Sat, 2007-05-12 at 11:27 +0200, Esben Nielsen wrote:
On Fri, 11 May 2007, Peter Zijlstra wrote:
I was toying with a scalable rw_mutex and found that it gives
On Wed, 2 May 2007, Ingo Molnar wrote:
* Balbir Singh [EMAIL PROTECTED] wrote:
The problem is with comparing a s64 values with (s64)ULONG_MAX, which
evaluates to -1. Then we check if exec_delta64 and fair_delta64 are
greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to
the
On Sat, 5 May 2007, Linus Torvalds wrote:
On Sat, 5 May 2007, Esben Nielsen wrote:
I have been wondering why you use usigned for timers anyway. It is also like
that in hrtimers. Why not use signed and avoid (almost) all worries about wrap
around issues. The trick is that when all
a b
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either not allow wrapping at all (in which case unsigned is better,
since it is bigger)
- or use wrapping
On Wed, 30 Mar 2005, Steven Rostedt wrote:
> [...]
>
> Heck, I'll make it bloat city till I get it working, and then tone it
> down a little :-) And maybe later we can have a better solution for the
> BKL.
>
What about removing it alltogether?
Seriously, how much work would it be to simply
On Thu, 31 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Well, here it finally is. There's still things I don't like about it.
> > But it seems to work, and that's the important part.
> >
> > I had to reluctantly add two items to the task_struct. I was
On Mon, 4 Apr 2005, Steven Rostedt wrote:
> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
>
> > > Currently my fix is in yield to lower the priority of the task calling
> > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > just a hack so I can get by it and
On Mon, 4 Apr 2005, Zwane Mwaikambo wrote:
> On Mon, 4 Apr 2005, Steven Rostedt wrote:
>
> > On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> >
> > > > Currently my fix is in yield to lower the priority of the task calling
> > > > yield and raise it after the schedule. This is NOT a
On Tue, 5 Apr 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > > Now the question is, who will fix it? Preferably the maintainers, but I
> > > don't know how much of a priority this is to them. I don't have the time
> > >
Hi, I am trying to compile and run UM-Linux with PREEMPT_REALTIME. I
managed to get it to compile but it wont start - it simply stops somewhere
in start_kernel() :-(
Have anyone else looked at it?
It doesn't sound like it makes much sense to have PREEMPT_REALTIME for UML
but I thought it was a
Well, I keep trying a little bit more. In the mean while you can get some
of the stuff I needed to change to at least get it to compile:
One of the problems was use of direct architecture specific semaphores
(which doesn't work under PREEMPT_REALTIME) and in places where a quick
(maybe too quick)
On Tue, 8 Feb 2005, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > Jeff, any objections against adding this change to UML at some point?
>
> No, not at all. I just need to understand what CONFIG_PREEMPT requires of
> UML.
Ingo can probably tell you in much more detail. My problem when I tried
On Tue, 8 Feb 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > Now I don't really know who I am responding to. But both up()s now
> > changed to complete()s are in something looking very much like an
> > interrupt handler. But a
I looked at the PI-code to see what priority the task (old_owner below)
would end up with when it released a lock. From rt.c:
prio = mutex_getprio(old_owner);
if (new_owner && !plist_empty(_owner->pi_waiters)) {
w = plist_entry(_owner->pi_waiters, struct
, Perez-Gonzalez, Inaky wrote:
> >From: Esben Nielsen [mailto:[EMAIL PROTECTED]
> >On 12 Apr 2005, Daniel Walker wrote:
> >
> >>
> >>
> >> At least, both mutexes will need to use the same API to raise and
> lower
> >> priorities.
> >
On 12 Apr 2005, Daniel Walker wrote:
>
> I just wanted to discuss the problem a little more. From all the
> conversations that I've had it seem that everyone is worried about
> having PI in Fusyn, and PI in the RT mutex.
>
> It seems like these two locks are going to interact on a very limited
On Fri, 28 Jan 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > I noticed that you changed rw-locks to behave quite diferently under
> > real-time preemption: They basicly works like normal locks now. I.e.
> > there can only be o
On 2 Feb 2005, Kevin Hilman wrote:
> While testing an older driver on an -RT kernel (currently using
> -V0.7.37-03), I noticed something strange.
>
> The driver was triggering a "sleeping function called from invalid
> context" BUG(). It was coming from a case where the driver was doing
> a
As I read the code the driver task (A) should _not_ be removed from the
runqueue. It has to be waken up to call schedule_timeout() such it gets
back on the runqueue after 10 ms. If it is taken out of the runqueue at
line 76 it will stay off the runqueue forever in the TASK_UNINTERRUBTIBLE
state!
On Fri, 18 Mar 2005, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > [...] How about something like:
> >
> > void
> > rcu_read_lock(void)
> > {
> > preempt_disable();
> > if (current->rcu_read_lock_nesting++ == 0) {
On Fri, 18 Mar 2005, Ingo Molnar wrote:
>
> * Bill Huey <[EMAIL PROTECTED]> wrote:
>
> > I'd like to note another problem. Mingo's current implementation of
> > rt_mutex (super mutex for all blocking synchronization) is still
> > missing reader counts and something like that would have to be
>
On Fri, 18 Mar 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > Why can should there only be one RCU-reader per CPU at each given
> > instance? Even on a real-time UP system it would be very helpfull to
> > have RCU areas to be e
On Sun, 20 Mar 2005, Paul E. McKenney wrote:
> On Sun, Mar 20, 2005 at 02:29:17PM +0100, Esben Nielsen wrote:
> > On Fri, 18 Mar 2005, Ingo Molnar wrote:
> >
> > > [...]
> >
> > I think it can be deterministic (on the long timescale of memory
> > mana
On Mon, 21 Mar 2005, Paul E. McKenney wrote:
> On Mon, Mar 21, 2005 at 12:23:22AM +0100, Esben Nielsen wrote:
> > > [...]
> > Well, I was actually thinking of an API like
> > preempt_by_nonrt_disable()
> > preempt_by_nonrt_enable()
> > working like the
On Tue, 22 Mar 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > On the other hand with a rw-lock being unlimited - and thus do not
> > keep track of it readers - the readers can't be boosted by the writer.
> > Then you are back to sq
On Tue, 22 Mar 2005, Bill Huey wrote:
> On Fri, Mar 18, 2005 at 05:55:44PM +0100, Esben Nielsen wrote:
> > On Fri, 18 Mar 2005, Ingo Molnar wrote:
> > > i really have no intention to allow multiple readers for rt-mutexes. We
> > > got away with that so far, and i'd like
On Tue, 22 Mar 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > +static inline void rcu_read_lock(void)
> > +{
> > + preempt_disable();
> > + __get_cpu_var(rcu_data).active_readers++;
> > + preempt_enable();
On Tue, 22 Mar 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > > > +static inline void rcu_read_lock(void)
> > > > +{
> > > > + preempt_disable();
> > > > + __get_cpu
On Tue, 22 Mar 2005, Paul E. McKenney wrote:
> On Tue, Mar 22, 2005 at 09:55:26AM +0100, Esben Nielsen wrote:
> > On Mon, 21 Mar 2005, Paul E. McKenney wrote:
> [ . . . ]
> > > On Mon, Mar 21, 2005 at 12:23:22AM +0100, Esben Nielsen wrote:
> > > This is in some wa
not RT.
> > 3. partially owned but the owner is RT and so is the grabber, and the
> > grabber's priority is >= the owner's priority.
>
> there's another approach that could solve this problem: let the
> scheduler sort it all out. Esben Nielsen had this sugge
I finally succeeded to get cg-clone to work on
linux/kernel/git/torvalds/linux-2.6.git
I can see the 2.6.13-rc4 is in there and can use cg-diff to see the
difference between the current tree and 2.6.13-rc4.
But how to I extract the 2.6.13-rc4 source from the tree?
Or even more complicated: I
On Wed, 24 Aug 2005, Jens Axboe wrote:
> On Wed, Aug 24 2005, Lee Revell wrote:
> > Just found this in dmesg.
> >
> > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229
> > caller is ___down_mutex+0xe9/0x1a0
> > [] schedule+0x59/0xf0 (8)
> > [] ___down_mutex+0xe9/0x1a0 (28)
>
On Fri, 15 Jul 2005, Daniel Walker wrote:
> On Fri, 2005-07-15 at 12:23 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > PI is always good, cause it allows the tracking of what is high
> > > priority , and what is not .
> >
> > that's just plain wrong. PI
On Thu, 14 Jul 2005, Christoph Hellwig wrote:
> On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> > This reminds me of Documentation/stable_api_nonsense.txt . That no one
> > should really be dependent on a particular kernel API doing a particular
> > thing. The kernel is play
On Wed, 27 Jul 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Perfectly understood. I've had two customers ask me to increase the
> > priorities for them, but those where custom kernels, and a config
> > option wasn't necessary. But since I've had customers
On Wed, 27 Jul 2005, K.R. Foley wrote:
> Esben Nielsen wrote:
> > On Wed, 27 Jul 2005, Ingo Molnar wrote:
> >
> >
> >>* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Perfectly understood. I've had two customers ask me
On Wed, 27 Jul 2005, Steven Rostedt wrote:
> On Wed, 2005-07-27 at 19:01 +0200, Esben Nielsen wrote:
> >
> > What for? Why can't you use FIFO at the same priorities for some of your
> > tasks? I pretty much quess you have a very few tasks which have some high
> > re
On Wed, 27 Jul 2005, K.R. Foley wrote:
> Esben Nielsen wrote:
> [...]
>
> All of the RT priorities that we have are not absolutely necessary. As I
> think Steven pointed out in another email, it is nice though to be able
> to priortize tasks using large jumps in priorities a
On Wed, 27 Jul 2005, Matt Porter wrote:
> On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
> > On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
> > > Kumar, I thought that we had some volunteers to take care of some of
> > > those. I know that I still care
On Fri, 26 Aug 2005, Matt Mackall wrote:
> On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote:
> > Ingo Molnar wrote:
> > >i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the
> > >usual place:
> > >
> > > http://redhat.com/~mingo/realtime-preempt/
> > >
> > >as
patch checks whether lp->next_tx already had an
> allocated buffer, and if so, it returns NETDEV_TX_BUSY. This prevents
> buffers from dissapearing under heavy traffic.
>
> This patch seems to work fine on my arcnet network, and I also sent it to
> the person (Esben Nielsen [E
1 - 100 of 127 matches
Mail list logo
