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:
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 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 behav
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 i
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:
> 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 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 ad
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 Thu, 2 Aug 2007, Ingo Molnar wrote:
> Most importantly, CFS _already_ includes a number of measures that act
> against too frequent math. So even though you can see 64-bit math code
> in it, it's only rarely called if your clock has a low resolution - and
> that happens all automaticall
Hi,
On Wed, 1 Aug 2007, Linus Torvalds wrote:
> So I think it would be entirely appropriate to
>
> - do something that *approximates* microseconds.
>
>Using microseconds instead of nanoseconds would likely allow us to do
>32-bit arithmetic in more areas, without any real overflow.
Th
Hi,
On Fri, 3 Aug 2007, Jonathan Corbet wrote:
> Most comments last time were favorable. The one dissenter was Roman,
> who worries about the overhead of using hrtimers for this operation; my
> understanding is that he would rather see a really_msleep() function for
> those who actually want mil
Hi,
On Fri, 3 Aug 2007, Arjan van de Ven wrote:
> On Fri, 2007-08-03 at 21:19 +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Fri, 3 Aug 2007, Jonathan Corbet wrote:
> >
> > > Most comments last time were favorable. The one dissenter was Roman,
> >
Hi,
On Fri, 3 Aug 2007, Arjan van de Ven wrote:
> > Actually the hrsleep() function would allow for submillisecond sleeps,
> > which might be what some of the 450 users really want and they only use
> > msleep(1) because it's the next best thing.
> > A hrsleep() function is really what makes mos
Hi,
On Sat, 4 Aug 2007, Arjan van de Ven wrote:
> > hr_msleep makes no sense. Why should we tie this interface to millisecond
> > resolution?
>
> because a lot of parts of the kernel think and work in milliseconds,
> it's logical and USEFUL to at least provide an interface that works on
> milli
Hi,
On Sun, 5 Aug 2007, Arjan van de Ven wrote:
> Timers are course resolution that is highly HZ-value dependent. For
> cases where you want a finer resolution, the kernel now has a way to
> provide that functionality... so why not use the quality of service this
> provides..
We're going in circ
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 didn
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 diff
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
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:
> > 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 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 Sat, 14 Jul 2007, Mike Galbraith wrote:
> > On Fri, 13 Jul 2007, Mike Galbraith wrote:
> >
> > > > The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> > > > attempt to scale that down a little...
> > >
> > > See prio_to_weight[], prio_to_wmult[] and sysctl_sched_st
Hi,
On Sat, 28 Jul 2007, Linus Torvalds wrote:
> We've had people go with a splash before. Quite frankly, the current
> scheduler situation looks very much like the CML2 situation. Anybody
> remember that? The developer there also got rejected, the improvement was
> made differently (and much
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
> > [...] e.g. in this example there are three tasks that run only for
> > about 1ms every 3ms, but they get far more time than should have
> > gotten fairly:
> >
> > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt
> > 4545 roman
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
> * Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > [...] the increase in code size:
> >
> > 2.6.22:
> >textdata bss dec hex filename
> > 10150 243344 1351834ce kernel/sched.
Hi,
On Wed, 1 Aug 2007, Andi Kleen wrote:
> > especially if one already knows that
> > scheduler clock has only limited resolution (because it's based on
> > jiffies), it becomes possible to use mostly 32bit values.
>
> jiffies based sched_clock should be soon very rare. It's probably
> not wort
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
> Please also send me the output of this script:
>
> http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
Send privately.
> Could you also please send the source code for the "l.c" and "lt.c" apps
> you used for your testing so i can
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
> > > in that case 'top' accounting symptoms similar to the above are not
> > > due to the scheduler starvation you suspected, but due the effect of
> > > a low-resolution scheduler clock and a tightly coupled
> > > timer/scheduler tick to it.
> >
>
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
> Andi's theory cannot be true either, Roman's debug info also shows this
> /proc//sched data:
>
> clock-delta : 95
>
> that means that sched_clock() is in high-res mode, the TSC is alive and
> kicking and a sched_cloc
Hi,
On Wed, 1 Aug 2007, Ingo Molnar wrote:
> > [...] I didn't say 'sleeper starvation' or 'rounding error', these are
> > your words and it's your perception of what I said.
>
> Oh dear :-) It was indeed my preception that yesterday you said:
*sigh* and here you go off again nitpicking on a mi
Hi,
On Wed, 1 Aug 2007, Peter Zijlstra wrote:
> Took me most of today trying to figure out WTH you did in fs2.c, more
> math and fundamental explanations would have been good. So please bear
> with me as I try to recap this thing. (No, your code was very much _not_
> obvious, a few comments and b
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 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 thin
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 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 Wed, 10 Jan 2007, Bernhard Schiffner wrote:
> > Without a further explanation of this craziness, it's a little hard to
> > discuss...
> Let's try it:
> time_constant is created for internal use of ntp.c and added by 4
> - time_constant = min(txc->constant + 4, (long)MAXTC);
>
Hi,
On Wed, 10 Jan 2007, Linus Torvalds wrote:
> > > I think your "current_thread_info()" is broken.
No, it's not. What is broken are our header dependencies - we happily mix
declarations with implementations.
Let's take a simple example like , which is practically
included everywhere, but eve
Hi,
On Wednesday 20 December 2006 02:32, john stultz wrote:
> > I know and all you have to change in the ntp and some related code is to
> > replace HZ there with a variable, thus make it changable, so you can
> > increase the update interval (i.e. it becomes 1s/hz instead of 1s/HZ).
>
> Untested
On Wednesday 20 December 2006 02:54, john stultz wrote:
> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.
Changing it to one creates a potential problem with calling second_overflow().
It should be called every NT
Hi,
On Thursday 28 December 2006 22:05, Adrian Bunk wrote:
> How to add some warning prints?
Simple, see the attached patch.
> And what's the problem with changing the generated files?
> There doesn't seem to be much activity in this area, and the noise of
> changing the generated files doesn't
Hi,
On Wednesday 21 February 2007 13:04, Rodolfo Giometti wrote:
> RFC simply doesn't consider the fact that you can have a PPS source
> __without__ a filedes connected with, and a single filedes is
> considered __always__ connected with a single PPS source.
That's not entirely true. It doesn't
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
> scripts: replace gawk, head, bc with shell, update
>
> Replacing overhead of using some (external) programs
> instead of good old `sh'.
awk is indeed a bit of overkill.
>
> Cc: Roman Zippel <[EMAIL PROTECTED]&g
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
> -- all checks by shell united in one macro -- checker-shell;
> -- one disposable output sym. link to /dev/null per shell,
>thus no racing, `-Z' is removed;
> -- modules' build output directory is used, if supplied;
> -- every option checking functi
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
> -nullstring :=
> -space := $(nullstring) # end of line
> +pattern = ".*/localversion[^~]*"
> +string = $(shell cat /dev/null \
> +`find $(objtree) $(srctree) -maxdepth 1 -regex $(pattern) | sort`)
Calling find here is overkill, if the sa
Hi,
On Wed, 7 Feb 2007, Alexey Dobriyan wrote:
> The change below is shitting i386 defconfig (as well as my usual config)
> build log with warnings:
>
> CC init/main.o
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instea
Hi,
On Wed, 7 Feb 2007, Oleg Verych wrote:
> > Linus, please revert. Thanks.
>
> Roman, while it went so fast to Linus, i didn't expect that, let me
> try to fix all this with this little patch.
Sorry, it needs more changes, the patch simply wasn't ready.
bye, Roman
-
To unsubscribe from this
Hi,
On Wed, 7 Feb 2007, Randy Dunlap wrote:
> > > > Linus, please revert. Thanks.
> > >
> > > Roman, while it went so fast to Linus, i didn't expect that, let me
> > > try to fix all this with this little patch.
> >
> > Sorry, it needs more changes, the patch simply wasn't ready.
>
> Can you
Hi,
On Wed, 7 Feb 2007, Linus Torvalds wrote:
> So I end up in a situation where I just basically will apply the patches
> just becauseif I don't, nothing ever happens. The good news is that _once_
> I apply them, people will usually notice problems and send in fixes fairly
> quickly. But this
Hi,
This reverts part of the localversion patch, which now already got into
git. It removes the unnecessary find call, with the simpler $(notdir ...)
fix.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile | 14 --
1 file changed, 8 insertions(+), 6 del
Hi,
On Thu, 8 Feb 2007, Oleg Verych wrote:
> -- `find | sort' in localversion (i insist on split between paths and
> files)
make has dedicated functions for this.
> -- symlinks to /dev/null in option checking -- isn't it better to not
>have any (though cached) access to files on filesys
Hi,
On Wed, 7 Feb 2007, Andrew Morton wrote:
> I'm sitting on these:
>
> search-a-little-harder-for-mkimage.patch
> make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
> add-mailmap-for-proper-git-shortlog-output.patch
> qconf-immediately-update-integer-and-string-values-in-xconfig-display-t
Hi,
On Thu, 8 Feb 2007, Oleg Verych wrote:
> BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
> compatibility with any `sh'. Shall we?
Wrong.
http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
bye, Roman
-
To unsubscribe from this list: send the line "unsubscri
per indentation
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile |9 --
scripts/Kbuild.include | 72 -
2 files changed, 42 insertions(+), 39 deletions(-)
Inde
Hi,
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> Historically, people used to do:
> - /bin/sh was the "standard shell" (bash)
> - /bin/[t]csh is what clueless weenies use for interactive work.
>
> (Yeah, I'm not a [t]csh fan ;)
>
> And you did break that.
>
> It's quite possible that all mode
Hi,
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> On Thu, 8 Feb 2007, Roman Zippel wrote:
>
> > I don't quite understand, the Makefile doesn't care anymore about /bin/sh
> > with this patch, the Makefile checks only for $BASH and /bin/bash
>
> Exactly.
&g
Hi,
On Fri, 9 Feb 2007, Andreas Schwab wrote:
> Roman Zippel <[EMAIL PROTECTED]> writes:
>
> > - printf has other side effects, instead stop pretending we support
> > something else than bash
>
> printf is a much better echo, but you need to use it properly as
Hi,
On Fri, 9 Feb 2007, Oleg Verych wrote:
> > - else if [ -x /bin/bash ]; then echo /bin/bash; \
> > - else echo sh; fi ; fi)
> > + else if [ -x /bin/bash ]; then echo /bin/bash; fi; fi)
> > +ifeq ($(CONFIG_SHELL),)
> > +$(error bash is required to build the kernel)
> > +endif
> > +S
Hi,
On Fri, 9 Feb 2007, Heiko Carstens wrote:
> And indeed all the __initdata annotated local and global variables on
> s390 are in the init.data section. So I'm wondering what this patch
> series is about. Or I must have missed something.
I think it reaches back to times when gcc 2.7.* was stil
it really makes sense to change the rules for this now,
apparently people are using this, it may not be perfect, but I think in
the end it's just a matter of taste.
bye, Roman
[PATCH] refix localversion handling
This reverts part of the localversion patch, which now already got into
git.
Hi,
On Wed, 14 Feb 2007, David Howells wrote:
> Now, this is not a complete solution by any means: the core kernel is not
> protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> controls) one relatively simple attack vector.
This is really the weak point - it offers no advan
Hi,
On Thu, 15 Feb 2007, David Howells wrote:
> > This is really the weak point - it offers no advantage over an equivalent
> > implementation in user space (e.g. in the module tools). So why has to be
> > done in the kernel?
>
> Because the init_module() system call is the common point of mod
Hi,
On Thu, 15 Feb 2007, David Lang wrote:
> this issue, and these holes keep comeing up in discussions, why can't these
> holes be closed? I seem to remember seeing patches that would remove /dev/kmem
> being sent to the list, but they weren't accepted into the kernel (and I seem
> to remember p
Hi,
On Thu, 15 Feb 2007, Kumar Gala wrote:
> I was wondering if there was some way to make a Kconfig menu either be just a
> menu or a choice depending on another bool being set or not.
>
> What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I want it so
> you can only select on opti
Hi,
On Sat, 17 Feb 2007, Oleg Verych wrote:
> could you make separate patch with exporting 'LANG=C' on the very
> beginning and delete all other occurrences of it? It's a C header file
> generation and afaik, it must be ASCII.
Bad idea, most user output should be localized (even if it's only utf
Hi,
On Fri, 16 Feb 2007, Olaf Hering wrote:
> Pass a timestamp to kbuild via an enviroment variable.
>
> TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
>
> This can be used when the kernel source is in a SCM and uname -v
> is supposed to give the commit date and not the package b
Hi,
On Sun, 18 Feb 2007, Olaf Hering wrote:
> > On Fri, 16 Feb 2007, Olaf Hering wrote:
> >
> > > Pass a timestamp to kbuild via an enviroment variable.
> > >
> > > TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
> > >
> > > This can be used when the kernel source is in a SCM and
Hi,
On Fri, 16 Feb 2007, Kumar Gala wrote:
> > Could you please be more specific about the problem you're trying to
> > solve, instead of how you're trying to solve it?
> > A real example would help a lot to understand the actual problem.
>
> Sure, on powerpc for some of the embedded sub-archite
Hi,
On Saturday 02 December 2006 17:02, Matthew Wilcox wrote:
> On Sat, Dec 02, 2006 at 03:45:12PM +0100, Thomas Gleixner wrote:
> > What's the cruft ?
> >
> > struct bla = container_of(timer, struct bla, timer); ???
>
> That's it, right there. Any idea how much we've bloated the kernel with
> s
Hi,
On Saturday 02 December 2006 19:40, Al Viro wrote:
> RTFPosting. It might be void *, but it's set via SETUP_TIMER which
> does type checks before casting to void *.
>
> IOW, I don't want _any_ typecasts/container_of necessary in the code.
>
> Sane variant is
>
> void foo_timer(struct net_dev
Hi,
On Sat, 2 Dec 2006, Al Viro wrote:
> > You need some more magic macros to access/modify the data field.
>
> Which is done bloody rarely. grep and you'll see... BTW, there are
> other reasons why passing struct timer_list * is wrong:
> * direct calls of the timer callback
Why should
Hi,
On Sat, 2 Dec 2006, Al Viro wrote:
> > > > You need some more magic macros to access/modify the data field.
> > >
> > > Which is done bloody rarely. grep and you'll see... BTW, there are
> > > other reasons why passing struct timer_list * is wrong:
> > > * direct calls of the timer callb
Hi,
On Sun, 3 Dec 2006, Russell King wrote:
> I agree with Al, Matthew and Pavel. The current timer stuff is a pita
> and needs fixing, and it seems Al has come up with a good way to do it
> without adding additional crap into every single user of timers.
What exactly is the pita here? Al only
Hi,
On Sun, 3 Dec 2006, Pavel Machek wrote:
> > What exactly is the pita here? Al only came up with some rather
> > theoretical problems with no practical relevance.
>
> Lack of type-checking in timers is ugly.
It's a matter of perspective, a bit more type checking would be nice, but
breaking
Hi,
On Monday 04 December 2006 16:39, Ingo Molnar wrote:
> there's *always* a way to do such things more cleanly - such as the
> patch below. Could you try to fix it up for 32-bit cycles_t platforms? I
> bet the hackery will be limited to now() and maybe the conversion
> routines, instead of spre
no further
justification was given for why it's needed.
Below is a replacement patch with some improvements:
- kbuild doesn't use $(AS), so use $(CC)
- tmp dir needs only to be calculated once
- reformat a bit to keep it under 80 columns and to be more readable
bye, Roman
Signed-off-by: Roman Zip
Hi,
On Mon, 4 Dec 2006, Andrew Morton wrote:
> [dyntick]
>
> Shall merge, I guess. My confidence is low, but it's Kconfigurable and it
> needs to get sorted out.
IMO it least at needs one more iteration to address the comments that
were made (not just mine), in the short term the less it to
Hi,
On Tue, 5 Dec 2006, Andrew Morton wrote:
> > IMO it least at needs one more iteration to address the comments that
> > were made (not just mine), in the short term the less it touches
> > unconditionally the less I care right now.
>
> I don't have a clue which review comments remain unaddr
Hi,
On Wed, 6 Dec 2006, Thomas Gleixner wrote:
> If I understand it correctly, Roman wants clockevents to be usable for
> other things aside hrtimer/dyntick, i.e. let other code request unused
> timer event hardware for special purposes. I thought about that in the
> originally but I stayed away
Hi,
On Wed, 6 Dec 2006, Ingo Molnar wrote:
> * Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 6 Dec 2006, Thomas Gleixner wrote:
> >
> > > If I understand it correctly, Roman wants clockevents to be usable
> > > for other things aside hr
Hi,
On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > > > > If I understand it correctly, Roman wants clockevents to be usable
> > > > > for other things aside hrtimer/dyntick, i.e. let other code request
> > > > > unused timer event hardware for special purposes. I thought about
> > > > > that in th
Hi,
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> To be honest, it'd be much easier if we only defined these operations on
> atomic_t's. We have all the infrastructure in place for them, and
> they're fairly well understood. If you need different sizes, I'm OK
> with an atomic_pointer_t, or whate
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > > To be honest, it'd be much easier if we only defined these operations on
> > > atomic_t's. We have all the infrastructure in place for them, and
> > > they're fairly well understood. If you need different sizes, I'm OK
> > > with an atomic_poi
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > > Any _real_ CPU will simply never care about _anything_ else than just the
> > > size of the datum in question.
> >
> > ..or alignment which a dedicated atomic type would allow to be attached.
>
> Can you give any example of a real CPU where a
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > m68060 produces a trap for unaligned atomic access, unfortunately standard
> > alignment is smaller than this.
>
> Umm. on 68060, since it's 32-bit, you'd only have the 32-bit case. Are you
> saying that you can't do a 32-bit atomic access at a
Hi,
On Tue, 12 Dec 2006, Pete Zaitcev wrote:
> In 2.6.19 (and Linus' curent tree), I found the following:
>
> libpath=$$dir/lib; lib=qt; osdir=""; \
> $(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \
> osdir=x$$($(HOSTCXX) -print-multi-os-directory); \
>
Hi,
On Tue, 12 Dec 2006, john stultz wrote:
> Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that the
> time code will use to accumulate with. In this patch I've pushed it out
> to a full second, but it could be set via config (NSEC_PER_SEC/HZ for
> regular systems, something larg
Hi,
On Wed, 13 Dec 2006, john stultz wrote:
> > The largest possible interval is freq cycles (or 1 second without
> > adjustments). That is the base interval and without redesigning NTP we
> > can't change that. This base interval can be subdivided into smaller
> > intervals for incremental updat
Hi,
On Tue, 19 Dec 2006, Kumar Gala wrote:
> Also, where do we stand with APUS?
Well, there are still patches umerged for over a year, they probably still
apply mostly.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
Hi,
On Mon, 18 Dec 2006, Adrian Bunk wrote:
> On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote:
> >
> > Remove the note in the documentation that suggests people can use
> > "requires" for dependencies in Kconfig files.
> >...
>
> Considering that noone uses it, what about the
On Friday 05 January 2007 11:44, Shlomi Fish wrote:
> > I would prefer it as separate smaller steps.
> > So one patch where you move the dialog and another where you improve
> > the search dialog.
>
> Move the dialog from where, to where, and in what respect?
Move the Find entry to a separate men
Hi,
On Thu, 4 Jan 2007, Cyrill V. Gorcunov wrote:
> qconf may cause SIGSEGV by trying to show debug
> information on empty menu items
Thanks, but this is more complex than necessary.
It simply lacks some initializers.
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
Hi,
On Tuesday 02 January 2007 20:42, john stultz wrote:
> > tick_nsec doesn't require special treatment, in the middle term it's
> > obsolete anyway, it could be replaced with (current_tick_length() >>
> > TICK_LENGTH_SHIFT) and current_tick_length() being inlined.
>
> If NTP_INTERVAL_FREQ is di
301 - 400 of 538 matches
Mail list logo
