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 c
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
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 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 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,
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,
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 to
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 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
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 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 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 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 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 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 d
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
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 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 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 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 <
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, 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 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 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 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 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
c
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 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 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, 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 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 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 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 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 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
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
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 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 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, 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
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*
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
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 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
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
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 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
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, 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 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)
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
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, 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 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
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, 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 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:
> > 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, 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, 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 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 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 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 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
, 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.
> >
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
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
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
> > >
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
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 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, 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 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 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 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 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
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
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 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
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
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, 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, 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:
>
> > 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
1 - 100 of 127 matches
Mail list logo
