Hi,
On Thu, 21 Feb 2008, David Howells wrote:
> The kernel NTP code shouldn't hand 64-bit *signed* values to do_div(). Make
> it
> instead hand 64-bit unsigned values. This gets rid of a couple of warnings.
I would actually prefer to introduce an explicit API for signed 64
divides to get rid
Hi,
On Thu, 21 Feb 2008, john stultz wrote:
> > Again, what kind of crappy hardware do you expect? Aren't clocks supposed
> > to get better and not worse?
>
> Well, while I've seen much worse, I consider crappy hardware to be 100
> +ppm error. So if the hardware is perfect and the system result
LOCK_TICK_ADJUST
completely. Add a optional kernel parameter ntp_tick_adj instead to allow
adjusting of a large base drift and thus keeping ntpd happy.
The CLOCK_TICK_ADJUST mechanism was introduced at a time PIT was the
primary clock, but we have a varity of clock sources now, so a global PIT
specific a
Hi,
On Mon, 18 Feb 2008, john stultz wrote:
> If we are building a train station, and each train car is 60ft, it
> doesn't make much sense to build 1000ft stations, right? Instead you'll
> do better if you build a 1020ft station.
That would assume trains are always 60ft long, which is the basic
Hi,
On Wed, 13 Feb 2008, john stultz wrote:
> Oh! So your issue is that since time_freq is stored in ppm, or in effect
> a usecs per sec offset, when we add it to something other then 1 second
> we mis-apply what NTP tells us to. Is that right?
Pretty much everything is centered around that 1sec
Hi,
On Wednesday 13. February 2008, Francis Moreau wrote:
> First I tried to find some documentation on the current implementation
> but haven't found any thing really usefull. Specially there's nothing about
> it in Documentation/ directory. Please correct me if I'm already wrong.
>
> Actually I
Hi,
On Wednesday 13. February 2008, Sam Ravnborg wrote:
> config foo
> tristate "do you want foo?"
> depends on USB && BAR
> module
> obj-$(CONFIG_FOO) += foo.o
> foo-y := file1.o file2.o
> help
> foo will allow you to explode your PC
I'm more thin
Hi,
On Mon, 11 Feb 2008, john stultz wrote:
> > I don't want to just send a patch, I want you to understand why your
> > approach is wrong.
>
> With all due respect, it also keeps the critique in one direction and
> makes your review less collaborative and more confrontational then I
> suspect
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
> -ENOPATCH
>
> We're taking weeks to critique fairly small bug fix. I'm sure we both
> have better things to do then continue to misunderstand each other. I'll
> do the testing and will happily ack it if it resolves the issue.
I don't want to just sen
Hi,
On Fri, 8 Feb 2008, Andrew Morton wrote:
> > Only now I noticed that the first patch had been merged without any
> > further question. :-(
> > What point is there in reviewing patches, if everything is merged anyway.
> > :-(
> >
>
> oops, mistake, sorry. There's plenty of time to fix it
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
>
> clock = clocksource_get_next();
> - clocksource_calculate_interval(clock,
> - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT));
> + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
> clock->cycle
Hi,
On Wed, 30 Jan 2008, Miklos Szeredi wrote:
> > How does this deal with certain special cases:
> > - chroot: how will mount/df only show the for chroot relevant mounts?
>
> That is a very good question. Andreas Gruenbacher had some patches
> for fixing behavior of /proc/mounts under a chroot
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
> > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
> > based on HZ, there is no point in using it!
>
> Hey Roman,
>
> Again, I'm sorry I don't seem to be following your objections. If you
> want to suggest a different patch
Hi,
On Wed, 30 Jan 2008, john stultz wrote:
> My concern is we state the accumulation interval is X ns long. Then
> current_tick_length() is to return (X + ntp_adjustment), so each
> accumulation interval we can keep track of the error and adjust our
> interval length.
>
> So if ntp_update_frequ
Hi,
On Tue, 29 Jan 2008, john stultz wrote:
> +/* Because using NSEC_PER_SEC would be too easy */
> +#define NTP_INTERVAL_LENGTH
> s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
Why are you using USER_HZ? Did you test this with HZ!=100?
Anyway, please don't make
Hi,
On Thursday 24. January 2008, Miklos Szeredi wrote:
> Q: Why do we need correct option showing in /proc/mounts?
> A: We want /proc/mounts to fully replace /etc/mtab. The reasons for
>this are:
> - unprivileged mounters won't be able to update /etc/mtab
> - /etc/mtab doesn't work
Hi,
On Mon, 28 Jan 2008, john stultz wrote:
> Regardless, current_tick_length() really is the base interval we're
> using in the error accumulation loop, so it seems the cleanest interface
> to use (just to avoid redundancy at least) when establishing the
> clocksource's interval length. Or do yo
Hi,
On Wed, 23 Jan 2008, john stultz wrote:
> This difference in calculation was causing the clocksource correction
> code to apply a correction factor to the clocksource so the two
> intervals were the same, however this results in the actual frequency of
> the clocksource to be made incorrect.
Hi,
On Wed, 16 Jan 2008, Sam Ravnborg wrote:
> But one feature I really would like to see is named chocies so we can do
> stuff like:
>
> choice X86_PROCESSOR
>
> config GENERIC_PROCESSOR
> bool "A generic X86 processor"
> endchoice
>
>
> ...
>
> choice PPC_PROCESSOR
>
> config GENER
Hi,
On Wed, 16 Jan 2008, Jan Beulich wrote:
> now that I finally found time to look into the problems that caused the
> patch changing boolean/tristate choice behavior to be reverted I find
> that due to the way things worked in the past there are a couple of
> cases where config options not real
Add the possibility to import a value from the environment into kconfig
via the option syntax. Beside flexibility this has the advantage
providing proper dependencies.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Documentation/kbuild/kconfig-language.txt | 21 ++
s
Use the environment option to provide the ARCH symbol.
Remove the unused KERNELVERSION symbol.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
init/Kconfig |4
scripts/kconfig/symbol.c | 14 --
2 files changed, 4 insertions(+), 14 deletions(-)
Rename E_CHOICE to E_LIST to explicitly add support for expression
lists. Add a helper macro expr_list_for_each_sym to more easily iterate
over the list.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c |8
scripts/kconfig/expr.c
Hi,
On Sun, 6 Jan 2008, Sam Ravnborg wrote:
> Please get back to me so we can finsih this patch and have it applied.
> I will split the patch in two btw.
I reworked the patch a little and split it into three.
> > + if (sym->flags & SYMBOL_AUTO)
> > + sym->flags &= ~SYMBOL_WRITE;
> >
Hi,
On Thursday 3. January 2008, Ph. Marek wrote:
> So I took a look at "Help", and saw that blob:
>
> Selected by: NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
> NETFILTER_XTABLES && (IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK
> || NETFILTER_XT_MATCH_CONNMARK && NET &&
Hi,
On Wednesday 2. January 2008, Eric Sandeen wrote:
> Roman, with this on top does it look better to you?
Looks good, thanks.
> I'll get hfsplus done in a bit.
I'm mainly concerned about brec.c/bfind.c, the patch should be pretty much
identical.
bye, Roman
--
To unsubscribe from this list:
Hi,
On Monday 17 December 2007, H. Peter Anvin wrote:
> kernel/timeconst.pl | 340
I agree with Jan that it would be better to put this into scripts.
In the long term we could also detect some of the simple special cases, so we
can finally inline some of these functions again, this w
Hi,
On Thursday 20 December 2007, Eric Sandeen wrote:
> Index: linux-2.6.24-rc3/fs/hfs/brec.c
> ===
> --- linux-2.6.24-rc3.orig/fs/hfs/brec.c
> +++ linux-2.6.24-rc3/fs/hfs/brec.c
> @@ -44,10 +44,21 @@ u16 hfs_brec_keylen(struct hfs_b
Hi,
On Sunday 16 December 2007, Geert Uytterhoeven wrote:
> --- a/init/main.c
> +++ b/init/main.c
> @@ -598,9 +598,9 @@ asmlinkage void __init start_kernel(void
>
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start && !initrd_below_start_ok &&
> - initrd_start < min_low_p
Hi,
On Wed, 28 Nov 2007, Paul Mundt wrote:
> Adrian mentioned a few weeks ago that KCONFIG_ALLCONFIG is the way to
> go to ensure that things like allyes/allmod/allnoconfig work with a
> constrained set of symbols, with the implication that this holds
> true for randconfig as well.
BTW another p
Hi,
On Thu, 15 Nov 2007, Randy Dunlap wrote:
> This all began (AFAIK) because some of us want to continue to be
> able to specify ARCH={i386,x86_64} on the (make) command line --
> not by using a .config file. Taking away ARCH= on the command line
> is a regression (in some minds, at least), so
Hi,
On Fri, 16 Nov 2007, Sam Ravnborg wrote:
> 1) make all*config, randconfig, defconfig is broken on 64-bit boxes
With your approach you made it impossible to set 64BIT from all*.config,
which is the proper way to set the defaults.
> 2) A pure code refactoring patch is reverted for no obvious
he kernel configuration - which
> your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
bye, Roman
Signed-off-by: Rom
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> > Can we please can get some consistency in this?
> > We have a .config file for a reason, what's wrong with using it?
>
> We need to set a selected few values in a few cases where we do
> not have a .config file.
> allmodconfig for x86 for instance
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> > > The value can be supplied on the command-line so we need to validate
> > > input.
> >
> > Is there a need for this?
> Yes. We would like to set 64BIT or not in other than x86 cases.
> And way forward was not to override ARCH as in the x86 case.
n doesn't depend on another (which is currently
enforced by the syntax).
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
init/Kconfig |4 ++
scripts/kconfig/expr.c | 16 +-
scripts/kconfig/expr.h
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
> + if (p) {
> + char warning[100];
> + sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> + conf_filename = warning;
> + def_flags = SYMBOL_DEF << def;
> + if (def == S_DEF
Hi,
On Fri, 9 Nov 2007, Jeff Garzik wrote:
> > > I switch between other cross-compiled arches (alpha, usually) on the
> > > makefile command line
> > >
> > > Yes, I know other 32/64-bit arches require .config editing. That
> > > doesn't change the basic fact that this is a workflow regression.
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
> As discussed in another thread the right thing is to add a generic solution
> to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
Could you please point me to this discussion?
Thanks.
bye, Roman
-
To unsubscribe from this list:
Hi,
On Thursday 01 November 2007, Ralf Baechle wrote:
> kernel/time/ntp.c contains the following piece of code:
>
> #define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
> #define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC)
> / \ (s64)CLOCK_TICK_RATE)
>
> static vo
Hi,
On Sunday 28 October 2007, Russell King wrote:
> On Sat, Oct 27, 2007 at 03:40:04PM -0700, Joe Perches wrote:
> > and forward declarations of
> >
> > struct proc_dir_entry;
> > struct file_operations;
> >
> > As a general rule, I think it better to use includes
> > than use naked forward decl
Hi,
On Thursday 25 October 2007, Sam Ravnborg wrote:
> > It's clearly invalid in that it depends on what it selects, but it should
> > just abort instead.
>
> Thanks for the report and especially for the testcase!
> I will try to look at it a bit later if noone bites me (I'm afraid not).
Well, y
Hi,
On Monday 22 October 2007, Randy Dunlap wrote:
> ~
> Another common idiom that we see (and sometimes have problems
> with) is this:
>
> When B (module or subsystem) uses interfaces from A (module or
> subsystem), A can be linked
Hi,
On Sun, 28 Oct 2007, Alexey Dobriyan wrote:
> > If it's just about the type checking, something like below should pretty
> > much do the same.
>
> It won't catch, the following if both variables are unsigned long:
>
> spin_lock_irqsave(&lock, flags);
> [stuff]
> s
Hi,
On Sun, 21 Oct 2007, Alexey Dobriyan wrote:
> So far remedies were:
> a) grep(1) -- obviously fragile. I tried at some point grepping for
>spin_lock_irqsave(), found quite a few, but it became bring quickly.
> b) BUILD_BUG_ON(sizeof(flags) != sizeof(unsigned long)) -- was tried,
>
Hi,
On Sat, 13 Oct 2007, Geert Uytterhoeven wrote:
> m68k: ignore restart_syscall, which is not needed on m68k.
It's somewhat needed, but nobody has gotten around to actually implement
it yet...
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hi,
On Mon, 1 Oct 2007, Oleg Verych wrote:
> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).
If you want to make such statements, you have to offer a little more than
the hot air y
Hi,
On Thu, 20 Sep 2007, Shlomi Fish wrote:
> Which specific problems do you see with the coding style of the patch? Can
> you
> comment on it?
Mostly whitespace around any braces, please keep it close to the other
source.
> > I would also prefer to move more of the search functionality into
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
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 gettin
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
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, 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
-
something like this, but initially I wanted to
keep 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 &
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.
>
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.
>
> Roman,
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 peop
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 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
> > c
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 tes
27;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 Zippel in the "Really Fair
>Schedule
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 Rea
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
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 http:/
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:0
===
--- /dev/null
+++ linux-2.6/kernel/sched_norm.c
@@ -0,0 +1,870 @@
+/*
+ * Completely Fair Scheduling (CFS) Class (SCHED_NORMAL/SCHED_BATCH)
+ *
+ * Copyright (C) 2007 Red Hat, Inc., Ingo Molnar <[EMAIL PROTECTED]>
+ *
+ * Interactivity improvements
=========
--- /dev/null
+++ linux-2.6/kernel/sched_norm.c
@@ -0,0 +1,841 @@
+/*
+ * Completely Fair Scheduling (CFS) Class (SCHED_NORMAL/SCHED_BATCH)
+ *
+ * Copyright (C) 2007 Red Hat, Inc., Ingo Molnar <[EMAIL PROTECTED]>
+ *
+ * Interactivity
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 ad
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:
> 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 yo
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 th
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 i
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 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 behav
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 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 ta
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
> 'norm
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 = 3
y one choice. The patch below 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
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 ma
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 wo
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 you
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
> wi
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 sma
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 thin
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 eas
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 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
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
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 o
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 add
1 - 100 of 538 matches
Mail list logo
