Hi,
On Thu, 13 Sep 2007, Shlomi Fish wrote:
This patch adds an option to use either substring match, regular expression
match, or keywords search in the make xconfig Edit-Find dialog.
It also allows searching on the help field of the menus as well as
the name of the symbol.
This
it simple. It's a compromise between overloading the user interface
with information and keeping it simple. That's the only concern I have
with it, but if everyone else likes I don't mind either. :)
Signed-off-by: Matěj Laitl [EMAIL PROTECTED]
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
bye, Roman
Hi,
On Sun, 16 Sep 2007, Sam Ravnborg wrote:
But can you take a look at distingushing between non-selectable options
due to dependency issues and seleted-by symbols.
Do you have an example in mind? If a symbol is not changable, but still
visible, a select is usually involved.
bye, Roman
-
Hi,
On Mon, 10 Sep 2007, Jan Beulich wrote:
--- linux-2.6.23-rc5/scripts/kconfig/menu.c 2007-09-07 16:48:23.0
+0200
+++ 2.6.23-rc5-tristate-choices/scripts/kconfig/menu.c2007-09-03
10:29:41.0 +0200
@@ -235,16 +235,23 @@ void menu_finalize(struct menu *parent)
Hi,
On Sun, 16 Sep 2007, Matej Laitl wrote:
+tristate sym_get_minimal_value(struct symbol *sym)
+{
+ return sym-rev_dep.tri;
+}
+
+tristate sym_get_maximal_value(struct symbol *sym)
+{
+ return sym-visible;
+}
+
Right now I prefer the previous version. This maximum value is
Hi,
On Sun, 16 Sep 2007, Matej Laitl wrote:
The v2 was maybe more intuitive, but had at least one flaw, where it claimed
the option was selected by another, while it was in fact only made
unchangeable by 'bool Enable block layer if EMBEDDED', defaulting to y.
The point is that I'm getting
Hi,
On Sun, 16 Sep 2007, Sam Ravnborg wrote:
On Sun, 16 Sep 2007, Sam Ravnborg wrote:
But can you take a look at distingushing between non-selectable options
due to dependency issues and seleted-by symbols.
Do you have an example in mind? If a symbol is not changable, but still
Hi,
On Fri, 14 Sep 2007, Arjan van de Ven wrote:
> > There is actually a very simple reason for that, the actual patch is
> > not my primary focus,
>
>
> for someone who's not focused on patches/code, you make quite a bit of
> noise when someone does turn your discussion into smaller patches
Hi,
On Fri, 14 Sep 2007, Arjan van de Ven wrote:
> > This is ridiculous, I asked you multiple times to explain to me some
> > of the differences relative to CFS as response to the splitup
> > requests. Not once did you react, you didn't even ask what I'd like
> > to know specifically.
>
>
Hi,
On Fri, 14 Sep 2007, Willy Tarreau wrote:
> On Aug 10th, I was disappointed to see that you still had not provided
> the critical information that Ingo had been asking to you for 9 days
> (cfs-sched-debug output). Your motivations in this work started to
> become a bit fuzzy to me, since
Hi,
On Thu, 13 Sep 2007, Sam Ravnborg wrote:
> I have read the announcement from Ingo and after reading it I concluded
> that it was good to see that Ingo had taken in consideration the feedback
> from you and improved the schduler based on this.
> And when I read that he removed a lot of stuff
Hi,
On Thu, 13 Sep 2007, Peter Zijlstra wrote:
> On Thu, 2007-09-13 at 18:50 +0200, Roman Zippel wrote:
>
> > I never claimed to understand every detail of CFS, I can _guess_ what
> > _might_ have been intended, but from that it's impossible to know for
> &g
Hi,
On Thu, 13 Sep 2007, Ingo Molnar wrote:
> > The rest of the math is indeed different - it's simply missing. What
> > is there is IMO not really adequate. I guess you will see the
> > differences, once you test a bit more with different nice levels.
>
> Roman, i disagree strongly. I did
Hi,
On Thu, 13 Sep 2007, Ingo Molnar wrote:
The rest of the math is indeed different - it's simply missing. What
is there is IMO not really adequate. I guess you will see the
differences, once you test a bit more with different nice levels.
Roman, i disagree strongly. I did test with
Hi,
On Thu, 13 Sep 2007, Peter Zijlstra wrote:
On Thu, 2007-09-13 at 18:50 +0200, Roman Zippel wrote:
I never claimed to understand every detail of CFS, I can _guess_ what
_might_ have been intended, but from that it's impossible to know for
certain how important they are. Let's take
Hi,
On Thu, 13 Sep 2007, Sam Ravnborg wrote:
I have read the announcement from Ingo and after reading it I concluded
that it was good to see that Ingo had taken in consideration the feedback
from you and improved the schduler based on this.
And when I read that he removed a lot of stuff I
Hi,
On Fri, 14 Sep 2007, Willy Tarreau wrote:
On Aug 10th, I was disappointed to see that you still had not provided
the critical information that Ingo had been asking to you for 9 days
(cfs-sched-debug output). Your motivations in this work started to
become a bit fuzzy to me, since people
Hi,
On Fri, 14 Sep 2007, Arjan van de Ven wrote:
This is ridiculous, I asked you multiple times to explain to me some
of the differences relative to CFS as response to the splitup
requests. Not once did you react, you didn't even ask what I'd like
to know specifically.
Roman,
this
Hi,
On Fri, 14 Sep 2007, Arjan van de Ven wrote:
There is actually a very simple reason for that, the actual patch is
not my primary focus,
for someone who's not focused on patches/code, you make quite a bit of
noise when someone does turn your discussion into smaller patches and
the idea to use absolute virtual time as the basic metric of
>scheduling has been first raised by William Lee Irwin, advanced by
>Tong Li and first prototyped by Roman Zippel in the "Really Fair
>Scheduler" (RFS) patchset.
>
>also see:
>
>
Hi,
On Thu, 13 Sep 2007, Ingo Molnar wrote:
> > Out of curiousity: will I ever get answers to my questions?
>
> the last few weeks/months have been pretty hectic - i get more than 50
> non-list emails a day so i could easily have missed some.
Well, let's just take the recent "Really Simple
Hi,
On Thu, 13 Sep 2007, Peter Zijlstra wrote:
> > There's a good reason
> > I put that much effort into maintaining a good, but still cheap average,
> > it's needed for a good task placement.
>
> While I agree that having this average is nice, your particular
> implementation has the
Hi,
On Thu, 13 Sep 2007, Peter Zijlstra wrote:
There's a good reason
I put that much effort into maintaining a good, but still cheap average,
it's needed for a good task placement.
While I agree that having this average is nice, your particular
implementation has the problem that it
Hi,
On Thu, 13 Sep 2007, Ingo Molnar wrote:
Out of curiousity: will I ever get answers to my questions?
the last few weeks/months have been pretty hectic - i get more than 50
non-list emails a day so i could easily have missed some.
Well, let's just take the recent Really Simple Really
se-vruntime
introduce se-vruntime as a sum of weighted delta-exec's, and use
that as the key into the tree.
the idea to use absolute virtual time as the basic metric of
scheduling has been first raised by William Lee Irwin, advanced by
Tong Li and first prototyped by Roman
Hi,
On Tue, 11 Sep 2007, Ingo Molnar wrote:
> fresh back from the Kernel Summit, Peter Zijlstra and me are pleased to
> announce the latest iteration of the CFS scheduler development tree. Our
> main focus has been on simplifications and performance - and as part of
> that we've also picked
Hi,
On Tue, 11 Sep 2007, Ingo Molnar wrote:
fresh back from the Kernel Summit, Peter Zijlstra and me are pleased to
announce the latest iteration of the CFS scheduler development tree. Our
main focus has been on simplifications and performance - and as part of
that we've also picked up
Hi,
Hi,
Out of curiousity: will I ever get answers to my questions?
bye, Roman
-
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
Hi,
On Tue, 11 Sep 2007, Mike Galbraith wrote:
> I still see the fairtest2 sleeper startup anomaly. Sometimes it starts
> up normally, others the sleeper is a delayed. Seems to require idle
> time to trigger worst case startup delay.
>
> 14854 root 20 0 1568 468 384 R 52 0.0
Hi,
On Tue, 11 Sep 2007, Mike Galbraith wrote:
I still see the fairtest2 sleeper startup anomaly. Sometimes it starts
up normally, others the sleeper is a delayed. Seems to require idle
time to trigger worst case startup delay.
14854 root 20 0 1568 468 384 R 52 0.0 0:07.50
Hi,
Hi,
Out of curiousity: will I ever get answers to my questions?
bye, Roman
-
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
(SCHED_NORMAL/SCHED_BATCH)
+ *
+ * Copyright (C) 2007 Red Hat, Inc., Ingo Molnar <[EMAIL PROTECTED]>
+ *
+ * Interactivity improvements by Mike Galbraith
+ * (C) 2007 Mike Galbraith <[EMAIL PROTECTED]>
+ *
+ * Various enhancements by Dmitry Adamushko.
+ * (C) 2007 Dmitry
]
+ *
+ * Scaled math optimizations by Thomas Gleixner
+ * Copyright (C) 2007, Thomas Gleixner [EMAIL PROTECTED]
+ *
+ * Really fair scheduling
+ * Copyright (C) 2007, Roman Zippel [EMAIL PROTECTED]
+ */
+
+typedef s64 kclock_t;
+
+static inline kclock_t kclock_max(kclock_t x, kclock_t y
P(se.sleep_max);
P(se.block_max);
P(se.exec_max);
Index: linux-2.6/kernel/sched_norm.c
===
--- /dev/null
+++ linux-2.6/kernel/sched_norm.c
@@ -0,0 +1,841 @@
+/*
+ * Completely Fair Scheduling (CFS) Class (SCHED_NO
PROTECTED]
+ *
+ * Really fair scheduling
+ * Copyright (C) 2007, Roman Zippel [EMAIL PROTECTED]
+ */
+
+typedef s64 kclock_t;
+
+static inline kclock_t kclock_max(kclock_t x, kclock_t y)
+{
+ return (kclock_t)(x - y) 0 ? x : y;
+}
+static inline kclock_t kclock_min(kclock_t x, kclock_t y
Hi,
On Tue, 4 Sep 2007, Ingo Molnar wrote:
> and what about the mirror image problem?
Sorry, I'm not familiar with that in a scheduler context.
> Your math assumes that tasks
> use up their full timeslices, somewhere starting at (12):
>
> | (12)time_norm_app = sum_{t}^{T}(time_norm_{t} *
Hi,
On Tue, 4 Sep 2007, Ingo Molnar wrote:
and what about the mirror image problem?
Sorry, I'm not familiar with that in a scheduler context.
Your math assumes that tasks
use up their full timeslices, somewhere starting at (12):
| (12)time_norm_app = sum_{t}^{T}(time_norm_{t} *
Hi,
On Mon, 3 Sep 2007, Ingo Molnar wrote:
> > It's a variation of the sleeper bonus. [...]
>
> hm, where are its effects described in your explanation? Seems like a
> key item.
It has no direct effect on the correctness of the mathematical model, the
time is initialized before the time is
Hi,
On Mon, 3 Sep 2007, Ingo Molnar wrote:
> My next question then is about this code of yours in the wakeup path:
>
> +static void
> +enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
> +{
> + kclock_t min_time;
> +
> + verify_queue(cfs_rq, cfs_rq->curr != se,
Hi,
On Mon, 3 Sep 2007, Ingo Molnar wrote:
> If this basic model is correct, we can look further.
The basic model is correct insofar I use an absolute time instead of a
relative time, but it's not the essence of my math, so I don't quite
understand the point of this exercise.
bye, Roman
-
To
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
> Roman, as an addendum to my review, please find below a prototype patch
> i've just written that implements RSRFS (Really Simple Really Fair
> Scheduler) ontop of CFS. It is intended to demonstrate the essence of
> the math you have presented via
Hi,
On Sun, 2 Sep 2007, Daniel Walker wrote:
> For instance if there are three tasks in the system. Call them A,B, and
> C.
>
> then
>
> time equals "time of A" + "time of B" + "time of C"
Ok, let's take a simple example. :)
If we have three task A, B, C, each with a weight of 1, 2, 3, so
Hi,
On Sun, 2 Sep 2007, Daniel Walker wrote:
For instance if there are three tasks in the system. Call them A,B, and
C.
then
time equals time of A + time of B + time of C
Ok, let's take a simple example. :)
If we have three task A, B, C, each with a weight of 1, 2, 3, so the
weight
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
Roman, as an addendum to my review, please find below a prototype patch
i've just written that implements RSRFS (Really Simple Really Fair
Scheduler) ontop of CFS. It is intended to demonstrate the essence of
the math you have presented via your
Hi,
On Mon, 3 Sep 2007, Ingo Molnar wrote:
If this basic model is correct, we can look further.
The basic model is correct insofar I use an absolute time instead of a
relative time, but it's not the essence of my math, so I don't quite
understand the point of this exercise.
bye, Roman
-
To
Hi,
On Mon, 3 Sep 2007, Ingo Molnar wrote:
My next question then is about this code of yours in the wakeup path:
+static void
+enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
+{
+ kclock_t min_time;
+
+ verify_queue(cfs_rq, cfs_rq-curr != se, se);
+
Hi,
On Mon, 3 Sep 2007, Ingo Molnar wrote:
It's a variation of the sleeper bonus. [...]
hm, where are its effects described in your explanation? Seems like a
key item.
It has no direct effect on the correctness of the mathematical model, the
time is initialized before the time is added
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
> > Did you even try to understand what I wrote? I didn't say that it's a
> > "common problem", it's a conceptual problem. The rounding has been
> > improved lately, so it's not as easy to trigger with some simple busy
> > loops.
>
> As i mentioned
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
> so i thought you must be aware of the problem - at least considering how
> much you've criticised CFS's "complexity" both in your initial review of
> CFS (which included object size comparisons) and in this patch
> submission of yours (which did
Hi,
On Sat, 1 Sep 2007, Bill Davidsen wrote:
> > I'd expect Ingo to know better, but the more he refuses to answer my
> > questions, the more I doubt it, at least than it comes to the math part.
> >
> The "math part" is important if you're doing a thesis defense, but
> demonstrating better
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
> And if you look at the resulting code size/complexity, it actually
> increases with Roman's patch (UP, nodebug, x86):
>
> textdata bss dec hex filename
> 13420 2281204 148523a04 sched.o.rc5
> 13554 228
Hi,
On Sat, 1 Sep 2007, Daniel Walker wrote:
> Out of curiosity I was reviewing your patch .. Since you create
> kernel/sched_norm.c as a copy of kernel/sched_fair.c it was hard to see
> what had changed .. So I re-diffed your patch to eliminate
> kernel/sched_norm.c and just make the changes to
Hi,
On Sat, 1 Sep 2007, Daniel Walker wrote:
Out of curiosity I was reviewing your patch .. Since you create
kernel/sched_norm.c as a copy of kernel/sched_fair.c it was hard to see
what had changed .. So I re-diffed your patch to eliminate
kernel/sched_norm.c and just make the changes to
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
And if you look at the resulting code size/complexity, it actually
increases with Roman's patch (UP, nodebug, x86):
textdata bss dec hex filename
13420 2281204 148523a04 sched.o.rc5
13554 228
Hi,
On Sat, 1 Sep 2007, Bill Davidsen wrote:
I'd expect Ingo to know better, but the more he refuses to answer my
questions, the more I doubt it, at least than it comes to the math part.
The math part is important if you're doing a thesis defense, but
demonstrating better behavior under
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
so i thought you must be aware of the problem - at least considering how
much you've criticised CFS's complexity both in your initial review of
CFS (which included object size comparisons) and in this patch
submission of yours (which did not
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
Did you even try to understand what I wrote? I didn't say that it's a
common problem, it's a conceptual problem. The rounding has been
improved lately, so it's not as easy to trigger with some simple busy
loops.
As i mentioned it in my
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
Maybe I should explain for everyone else (especially after seeing some of
the comments on kerneltrap), why I reacted somewhat irritated on what
looks like such an innocent mail.
The problem is without the necessary background one can't know how wrong
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
Maybe I should explain for everyone else (especially after seeing some of
the comments on kerneltrap), why I reacted somewhat irritated on what
looks like such an innocent mail.
The problem is without the necessary background one can't know how wrong
Hi,
On Fri, 31 Aug 2007, Mike Galbraith wrote:
> I plunked it into 2.6.23-rc4 to see how it reacts to various sleeper
> loads, and hit some starvation. If I got it in right (think so) there's
> a bug lurking somewhere. taskset -c 1 fairtest2 resulted in the below.
> It starts up running both
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
> So the most intrusive (math) aspects of your patch have been implemented
> already for CFS (almost a month ago), in a finegrained way.
Interesting claim, please substantiate.
> Peter's patches change the CFS calculations gradually over from
>
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
So the most intrusive (math) aspects of your patch have been implemented
already for CFS (almost a month ago), in a finegrained way.
Interesting claim, please substantiate.
Peter's patches change the CFS calculations gradually over from
Hi,
On Fri, 31 Aug 2007, Mike Galbraith wrote:
I plunked it into 2.6.23-rc4 to see how it reacts to various sleeper
loads, and hit some starvation. If I got it in right (think so) there's
a bug lurking somewhere. taskset -c 1 fairtest2 resulted in the below.
It starts up running both tasks
Hi,
On Friday 24 August 2007, Linus Torvalds wrote:
> Why the hell can't you just make the code sane and do what the comment
> *says* it does, and just admit that HZ has nothing what-so-ever to do with
> that thing, and then you do
>
> unsigned int sysctl_sched_granularity __read_mostly =
Hi,
On Friday 24 August 2007, Linus Torvalds wrote:
Why the hell can't you just make the code sane and do what the comment
*says* it does, and just admit that HZ has nothing what-so-ever to do with
that thing, and then you do
unsigned int sysctl_sched_granularity __read_mostly =
avoids the setting of the value here.
bye, Roman
Avoid setting the value if the symbol doesn't need to be changed or can't
be changed. Later choices may change the dependencies and thus the
possible input range.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/con
may change the dependencies and thus the
possible input range.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
scripts/kconfig/conf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
Index: linux-2.6/scripts/kconfig/conf.c
Hi,
On Thu, 23 Aug 2007, Avi Kivity wrote:
> Pointing out that this
> is a Kconfig bug does not seem to silence the error,
*sigh*
This is not a Kconfig bug!
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hi,
On Thu, 23 Aug 2007, Avi Kivity wrote:
Pointing out that this
is a Kconfig bug does not seem to silence the error,
*sigh*
This is not a Kconfig bug!
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Hi,
On Tue, 21 Aug 2007, Andres Salomon wrote:
> > I would really like to avoid another input mode.
> > I think it be better to implement this as a combination of "-s -D
> > " and the silent mode is adjusted to read another config instead
> > of .config if defconfig_file is set.
> >
>
> As
Hi,
On Mon, 20 Aug 2007, Andres Salomon wrote:
> AFAICT, there is nothing similar when using *_defconfig; one must copy
> a .config manually, and then run silentoldconfig. Simply running the
> associated _defconfig will quietly update the config (which may silently
> drop config options). This
Hi,
On Sat, 18 Aug 2007, Marco Costalba wrote:
> When 'Show debug info' is checked then a list of links
> to dependant symbols is shown in info view right bottom pane.
>
> Currently all links are in standard blue. With this patch
> links to disabled symbols are shown in red instead.
The way
Hi,
On Tue, 21 Aug 2007, Mike Galbraith wrote:
> I thought this was history. With your config, I was finally able to
> reproduce the anomaly (only with your proggy though), and Ingo's patch
> does indeed fix it here.
>
> Freshly reproduced anomaly and patch verification, running 2.6.23-rc3
>
Hi,
On Tue, 21 Aug 2007, Mike Galbraith wrote:
I thought this was history. With your config, I was finally able to
reproduce the anomaly (only with your proggy though), and Ingo's patch
does indeed fix it here.
Freshly reproduced anomaly and patch verification, running 2.6.23-rc3
with
Hi,
On Sat, 18 Aug 2007, Marco Costalba wrote:
When 'Show debug info' is checked then a list of links
to dependant symbols is shown in info view right bottom pane.
Currently all links are in standard blue. With this patch
links to disabled symbols are shown in red instead.
The way you
Hi,
On Mon, 20 Aug 2007, Andres Salomon wrote:
AFAICT, there is nothing similar when using *_defconfig; one must copy
a .config manually, and then run silentoldconfig. Simply running the
associated _defconfig will quietly update the config (which may silently
drop config options). This
Hi,
On Tue, 21 Aug 2007, Andres Salomon wrote:
I would really like to avoid another input mode.
I think it be better to implement this as a combination of -s -D
default and the silent mode is adjusted to read another config instead
of .config if defconfig_file is set.
As would I;
Hi,
On Sat, 11 Aug 2007, Ingo Molnar wrote:
> the only relevant thing that comes to mind at the moment is that last
> week Peter noticed a buggy aspect of sleeper bonuses (in that we do not
> rate-limit their output, hence we 'waste' them instead of redistributing
> them), and i've got the
Hi,
On Sat, 11 Aug 2007, Ingo Molnar wrote:
the only relevant thing that comes to mind at the moment is that last
week Peter noticed a buggy aspect of sleeper bonuses (in that we do not
rate-limit their output, hence we 'waste' them instead of redistributing
them), and i've got the small
Hi,
On Fri, 10 Aug 2007, Ingo Molnar wrote:
> achieve that. It probably wont make a real difference, but it's really
> easy for you to send and it's still very useful when one tries to
> eliminate possibilities and when one wants to concentrate on the
> remaining possibilities alone.
The
Hi,
On Fri, 10 Aug 2007, Willy Tarreau wrote:
> fortunately all bug reporters are not like you. It's amazing how long
> you can resist sending a simple bug report to a developer!
I'm more amazed how long Ingo can resist providing some explanations (not
just about this problem).
It's not like I
Hi,
On Fri, 10 Aug 2007, Michael Chang wrote:
> On 8/10/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
> > Is there any reason to believe my analysis is wrong?
>
> Not yet, but if you give Ingo what he wants (as opposed to what you're
> giving him) it'll be easier for hi
Hi,
On Fri, 10 Aug 2007, Mike Galbraith wrote:
> I guess I'm going to have to give up on trying to reproduce this... my
> 3GHz P4 is just not getting there from here. Last attempt, compiled UP,
> HZ=1000 dynticks, full preempt and highres timers fwiw.
>
> 6392 root 20 0 1696 332 248
Hi,
On Fri, 10 Aug 2007, Ingo Molnar wrote:
> > I disabled the jiffies logic and the result is still the same, so this
> > problem isn't related to resolution at all.
>
> how did you disable the jiffies logic?
I commented it out.
> Also, could you please send me
> the cfs-debug-info.sh:
>
Hi,
On Fri, 10 Aug 2007, Michael Chang wrote:
On 8/10/07, Roman Zippel [EMAIL PROTECTED] wrote:
Is there any reason to believe my analysis is wrong?
Not yet, but if you give Ingo what he wants (as opposed to what you're
giving him) it'll be easier for him to answer what's going wrong
Hi,
On Fri, 10 Aug 2007, Mike Galbraith wrote:
I guess I'm going to have to give up on trying to reproduce this... my
3GHz P4 is just not getting there from here. Last attempt, compiled UP,
HZ=1000 dynticks, full preempt and highres timers fwiw.
6392 root 20 0 1696 332 248 R
Hi,
On Fri, 10 Aug 2007, Ingo Molnar wrote:
I disabled the jiffies logic and the result is still the same, so this
problem isn't related to resolution at all.
how did you disable the jiffies logic?
I commented it out.
Also, could you please send me
the cfs-debug-info.sh:
Hi,
On Fri, 10 Aug 2007, Willy Tarreau wrote:
fortunately all bug reporters are not like you. It's amazing how long
you can resist sending a simple bug report to a developer!
I'm more amazed how long Ingo can resist providing some explanations (not
just about this problem).
It's not like I
Hi,
On Fri, 10 Aug 2007, Ingo Molnar wrote:
achieve that. It probably wont make a real difference, but it's really
easy for you to send and it's still very useful when one tries to
eliminate possibilities and when one wants to concentrate on the
remaining possibilities alone.
The thing
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
> just to make sure, how does 'top' output of the l + "lt 3" testcase look
> like now on your laptop? Yesterday it was this:
>
> 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt
> 4545 roman 20 0 1796 344 256 R 32.1 0.3
Hi,
On Tue, 7 Aug 2007, Andrew Morton wrote:
> > The current msleep is fine and doesn't need any "fixing".
> > Not all the world is i386, _please_ keep hrtimer usage where it's
> > required. Simple timer should be given preference unless the higher
> > resolution is really needed, which is not
Hi,
On Tue, 7 Aug 2007, Andrew Morton wrote:
The current msleep is fine and doesn't need any fixing.
Not all the world is i386, _please_ keep hrtimer usage where it's
required. Simple timer should be given preference unless the higher
resolution is really needed, which is not the case
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
just to make sure, how does 'top' output of the l + lt 3 testcase look
like now on your laptop? Yesterday it was this:
4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt
4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt
On Tue, 7 Aug 2007, Andrew Morton wrote:
> On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
> Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Tue, 7 Aug 2007, Andrew Morton wrote:
> >
> > > I'd be surprised if there was significant overhe
Hi,
On Tue, 7 Aug 2007, Andrew Morton wrote:
> I'd be surprised if there was significant overhead - the maximum frequency
> at which msleep() can be called is 1000Hz. We'd need an awful lot of
> overhead for that to cause problems, surely?
>
>
_Anybody_ has yet to answer what's wrong with
Hi,
On Mon, 6 Aug 2007, Arjan van de Ven wrote:
> So, let me ask a direct question: What do you think is specifically
> wrong about changing the msleep() implementation as is done here? The
> behavior is clearly an improvement, so what is your objection on the
> flipside?
Again, we have two
Hi,
On Mon, 6 Aug 2007, Arjan van de Ven wrote:
So, let me ask a direct question: What do you think is specifically
wrong about changing the msleep() implementation as is done here? The
behavior is clearly an improvement, so what is your objection on the
flipside?
Again, we have two
Hi,
On Tue, 7 Aug 2007, Andrew Morton wrote:
I'd be surprised if there was significant overhead - the maximum frequency
at which msleep() can be called is 1000Hz. We'd need an awful lot of
overhead for that to cause problems, surely?
thinks he's missing something again
_Anybody_ has yet
On Tue, 7 Aug 2007, Andrew Morton wrote:
On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Tue, 7 Aug 2007, Andrew Morton wrote:
I'd be surprised if there was significant overhead - the maximum frequency
at which msleep() can be called
Hi,
On Sun, 5 Aug 2007, Arjan van de Ven wrote:
> > There's no problem to provide a high resolution sleep, but there is also
> > no reason to mess with msleep, don't fix what ain't broken...
>
> John Corbet provided the patch because he had a problem with the current
> msleep... in that it
101 - 200 of 1055 matches
Mail list logo
