this is the v2 release of the syslet subsystem. This is an interim
release, not all known and pending items are fixed/changed yet - the
tree is still work in progress:
http://redhat.com/~mingo/syslet-patches/
The biggest conceptual change in v2 is the ability of cachemiss threads
to be
From: Ingo Molnar [EMAIL PROTECTED]
add include/linux/async.h which contains the kernel-side API
declarations.
it also provides NOP stubs for the !CONFIG_ASYNC_SUPPORT case.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
include/linux/async.h
From: Ingo Molnar [EMAIL PROTECTED]
provide an optimized assembly version of the copy_uatom() method.
This is about 3 times faster than the C version.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
arch/i386/lib/getuser.S | 115
* Ingo Molnar [EMAIL PROTECTED] wrote:
Index: linux/kernel/async.h
===
--- /dev/null
+++ linux/kernel/async.h
@@ -0,0 +1,2 @@
+
+
this one sneaked in accidentally - i have removed it from my queue now.
Ingo
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
Rui Nuno Capela (me) 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. For the first case I could
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007, Linus Torvalds wrote:
So I think that a good implementation just does everything up-front,
and doesn't _need_ a user buffer that is live over longer periods,
except for the actual results. Exactly because the whole
* Eric W. Biederman [EMAIL PROTECTED] wrote:
So I propose we remove all assumptions from the code that we actually
have an array of irqs. That will allow for irq_desc to be dynamically
allocated instead of statically allocated saving memory and reducing
kernel complexity.
hm. I'd
the dropped cpu_relax() back to the wait loops.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
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
* Nicholas Miell [EMAIL PROTECTED] wrote:
The X people have plans for how to go about fixing this, [...]
then we'll first have wait for those X changes to at least be done in a
minimal manner so that they can be tested for real with RSDL. (is it
_really_ due to that? Or will X regress
* Nicholas Miell [EMAIL PROTECTED] wrote:
I'm saying that the current scheduler adjusts for interactive loads,
this new one doesn't. I'm seeing interactivity regressions, and
they are not fixed with nice unless nice is used to maximum effect.
I'm saying yes, I can lower my
.
( NOTE: more improvements are possible as well: right now most
interactivity calculations are still done even if CONFIG_SCHED_FAIR is
enabled - that could be improved upon. )
Ingo
--
Subject: [patch] CFS scheduler: Completely Fair Scheduler
From: Ingo Molnar
* Con Kolivas [EMAIL PROTECTED] wrote:
Despite the claims to the contrary, RSDL does not have _less_
heuristics, it does not have _any_. It's purely entitlement based.
RSDL still has heuristics very much, but this time it's hardcoded into
the design! Let me demonstrate this via a simple
* Con Kolivas [EMAIL PROTECTED] wrote:
We're obviously disagreeing on what heuristics are [...]
that could very well be so - it would be helpful if you could provide
your own rough definition for the term, so that we can agree on how to
call things?
[ in any case, there's no rush here,
* jos poortvliet [EMAIL PROTECTED] wrote:
Op Saturday 17 March 2007, schreef Ingo Molnar:
so it is not at all clear to me that RSDL is indeed an improvement,
if it does not have comparable auto-nice properties.
Wasn't the point of RSDL to get rid of the auto-nice, because it
caused
to be a SCHED_BATCH process.
*
* Copyright (C) 2002 Ingo Molnar
*/
#include time.h
#include stdio.h
#include sched.h
#include stdlib.h
#include sys/types.h
#include linux/unistd.h
int main (int argc, char **argv)
{
int pid, ret;
struct sched_param p;
p.sched_priority = 0
* Con Kolivas [EMAIL PROTECTED] wrote:
Ok but please look at how it appears from my end (illness aside).
( i really think we should continue this debate after you get better.
Everything looks much darker when you are ill! )
You initially said you were pleased with this design.
I said
* Pavel Machek [EMAIL PROTECTED] wrote:
Some day we may have modesetting support in the kernel for some
graphics hw, right now it's pretty damn spotty.
Yep, that's the way to go.
hey, i wildly supported this approach ever since 1996, when GGI came up
:-/
Ingo
-
To unsubscribe
* Xavier Bestel [EMAIL PROTECTED] wrote:
On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote:
I don't agree with starting to renice X to get something usable
[...] Why not compensate for X design by prioritizing it a bit ?
there were multiple attempts with renicing X under the vanilla
* Linus Torvalds [EMAIL PROTECTED] wrote:
I have this dim memory that ARM has done it that way for a long time
because it's so expensive to do a real cli/sti.
And I think -rt does it for other reasons. It's just more flexible.
-rt doesnt wrap cli/sti anymore: spin_lock_irq*() doesnt
-States behind the kernels back. This delays the
local apic timer interrupts for ever and makes the systems unusable.
Add a command line option to disable the local apic timer and a dmi
quirk for known broken systems.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Acked-by: Ingo Molnar
Zijlstra [EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
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
[EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
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://www.tux.org
* Mike Galbraith [EMAIL PROTECTED] wrote:
Actually, the numbers are an interesting curiosity point, but not as
interesting as the fact that the deadline mechanism isn't kicking in.
it's not just the scheduling accounting being off, RSDL also seems to be
accessing stale data here:
From
.
Ingo
---
Subject: [patch] setup_boot_APIC_clock() irq-enable fix
From: Ingo Molnar [EMAIL PROTECTED]
latest -git triggers an irqtrace/lockdep warning of a leaked
irqs-off condition:
BUG: at kernel/fork.c:1033 copy_process()
after some debugging it turns out that commit
* Michal Piotrowski [EMAIL PROTECTED] wrote:
BUG: at kernel/fork.c:1033 copy_process()
thanks Michal - this is a real bug that affects upstream too. Find
the fix below - i've test-booted it and it fixes the warning.
Problem is fixed, thanks.
BTW. It seems that nobody uses -rt
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Hibernation is still broken.
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4-rt0/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4-rt0/rt-config
what's the failure mode besides the
* Nick Piggin [EMAIL PROTECTED] wrote:
Implement queued spinlocks for i386. [...]
isnt this patented by MS? (which might not worry you SuSE/Novell guys,
but it might be a worry for the rest of the world ;-)
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
there's a new post-rc4 regression: my T60 hangs during early bootup. I
bisected the hang down to this recent commit:
| commit 25496caec111481161e7f06bbfa12a533c43cc6f
| Author: Thomas Renninger [EMAIL PROTECTED]
| Date: Tue Feb 27 12:13:00 2007 -0500
|
|ACPI: Only use IPI on known broken
.
if the hang occurs again then please do a SysRq-Q again and send us the
output.
Ingo
Subject: [patch] hrtimers debug patch
From: Ingo Molnar [EMAIL PROTECTED]
debugging helper for hrtimers. Keep a lookout for WARN_ON messages.
Saves a stacktrace on every expires_next
* Linus Torvalds [EMAIL PROTECTED] wrote:
[ Ok, I think it's those timers again...
agreed - this seems to be a genuine CONFIG_HIGH_RES_TIMERS=y bug. (which
has probably not been fixed since -rc4 either, we have no bugfix in this
area that could explain the expires_next==KTIME_MAX timer state
* Nikita Danilov [EMAIL PROTECTED] wrote:
Indeed, this technique is very well known. E.g.,
http://citeseer.ist.psu.edu/anderson01sharedmemory.html has a whole
section (3. Local-spin Algorithms) on them, citing papers from the
1990 onward.
that is a cool reference! So i'd suggest to do
* Ray Lee [EMAIL PROTECTED] wrote:
Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to
itself
Ray Lee reported, that on an UP kernel with noapic command line
option set, the box locks hard during boot.
i think this bug deserves a bit more attention, because similar problems
reported against -mm some time ago.
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
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
* Guillaume Chazarain [EMAIL PROTECTED] wrote:
+static int tsc_enabled;
So, now we have tsc_disable, tsc_enabled and tsc_unstable. I can
understand the latter, but this lacks orthogonality IMHO.
tsc_disable should be renamed to tsc_disable_override or so, to signal
that it's only the
* Roland Dreier [EMAIL PROTECTED] wrote:
OK, another data point. The config below boots and works with
2.6.21-rc4-rt1, but enabling CONFIG_CRITICAL_IRQSOFF_TIMING causes the
early boot hang.
Any idea?
ah, i havent tried that option in quite some time, so bitrot is pretty
likely. Does
* Roland Dreier [EMAIL PROTECTED] wrote:
I'm trying to use 2.6.21-rc4-rt1 to track down who's keeping
interrupts off for too long. [...]
btw., is this something you know for sure (if yes, how do you know?) -
or is it that you would like to double-check the irqs-off times of
v2.6.21-to-be?
* Ingo Molnar [EMAIL PROTECTED] wrote:
OK, another data point. The config below boots and works with
2.6.21-rc4-rt1, but enabling CONFIG_CRITICAL_IRQSOFF_TIMING causes the
early boot hang.
ah, i havent tried that option in quite some time, so bitrot is pretty
likely. Does
. This increases overhead slightly but
avoids the problem of tick aliasing errors making accounting unreliable.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
include/linux/kernel_stat.h |3 ++
include/linux/sched.h |2 -
kernel/sched.c
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm - on 32-bit, CRITICAL_IRQSOFF_TIMING+FUNCTION_TRACING works fine
for me. I'll try the 64-bit kernel too.
the 64-bit kernel indeed hangs. Does the patch below fix it for you?
Ingo
Index: linux/kernel/timer.c
but
avoids the problem of tick aliasing errors making accounting unreliable.
Signed-off-by: Con Kolivas [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
include/linux/kernel_stat.h |3 ++
include/linux/sched.h |2 -
kernel/sched.c | 46
-by: Ingo Molnar [EMAIL PROTECTED]
---
Index: linux-2.6/kernel/time/ntp.c
===
--- linux-2.6.orig/kernel/time/ntp.c
+++ linux-2.6/kernel/time/ntp.c
@@ -196,7 +196,7 @@ void __attribute__ ((weak)) notify_arch_
*/
int do_adjtimex(struct
* Thomas Gleixner [EMAIL PROTECTED] wrote:
Sorry, now I'm confused.
Could you pls list the full set of tests you want me to run,
and what information to collect from each of them?
1. Test:
I suspect step 0 would be use Linus' latest tree, ontop of -rc4:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Sun, 25 Mar 2007, Thomas Gleixner wrote:
Environment: Pre Pentium systems, (boot_cpu_data.wp_works_ok == 0)
This shouldn't be pre-pentium, afaik. WP-works-ok on i486 too. I
think only the original i386 had this bug (feature).
But I agree,
* Con Kolivas [EMAIL PROTECTED] wrote:
The patches available also include a rollup of sched: accurate user
accounting as this code touches the same area and it is most
convenient to include them together.
as i mentioned it before, please keep this one separate, as we want to
apply it
* Ingo Molnar [EMAIL PROTECTED] wrote:
The patches available also include a rollup of sched: accurate user
accounting as this code touches the same area and it is most
convenient to include them together.
as i mentioned it before, please keep this one separate, as we want to
apply
* Nicolas Boichat [EMAIL PROTECTED] wrote:
I found out which commit seems to cause these bugs:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d04f41e35343f1d788551fd3f753f51794f4afcf
The latest GIT without this commit works fine, but doesn't with it.
* Ingo Molnar [EMAIL PROTECTED] wrote:
my first quick guess was to extend np-priv locking to the whole of
nv_start_xmit/nv_start_xmit_optimized - while that appeared to make
the crash a bit less likely, it did not prevent it. So there must be
some other, more fundamental problem
* Ingo Molnar [EMAIL PROTECTED] wrote:
my first quick guess was to extend np-priv locking to the whole of
nv_start_xmit/nv_start_xmit_optimized - while that appeared to make
the crash a bit less likely, it did not prevent it. So there must be
some other, more fundamental problem be left
* Linus Torvalds [EMAIL PROTECTED] wrote:
There's various fixes here, ranging from some architecture updates
(ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
here's a new v2.6.20 - v2.6.21 forcedeth.c regression:
in the last week or so i've been seeing sporadic
* Thomas Gleixner [EMAIL PROTECTED] wrote:
The current sysfs support of clockevents does not obey the only one
value per file rule.
The real fix is not 2.6.21 material. Therefor remove the sysfs support
for now.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Acked-by: Ingo Molnar
hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Tx Queue 0
TDH ec
TDT ec
next_to_use
* Wu, Bryan [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_MMU
struct mm_struct *mm = vma-vm_mm;
+#else
+ struct mm_struct *mm = 0;
+#endif
s/0/NULL ?
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
attached below. Patch is
build and boot-tested.
Ingo
--
Subject: [patch] hrtimers: fix reprogramming SMP race
From: Ingo Molnar [EMAIL PROTECTED]
hrtimer_start() incorrectly set the 'reprogram' flag to
enqueue_hrtimer(), which should only be 1 if the hrtimer is queued
* Jesse Brandeburg [EMAIL PROTECTED] wrote:
was there a NETDEV WATCHDOG message that follows this? If not it is
a harmless debug print. Note the time_stamp and jiffies difference,
very large, consistent with a resume. I think we need to disable the
internal e1000 tx hang code that
* Venki Pallipadi [EMAIL PROTECTED] wrote:
Ingo,
Does the patch below help?
Patch to resolve maxcpus=1 trigerring BUG() as reported by Ingo here
yes, it solves it, thanks!
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
To unsubscribe from this list: send the line unsubscribe
* Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Note that I'm not opposed to the change at all, I think it's a good
idea, I'm just worried I'm discovering it a bit late and I've seen
PICs broken in some many colorful ways that I'm a bit worried... Oh
well...
This change does not really
* Con Kolivas [EMAIL PROTECTED] wrote:
Nice -10 on mainline ruins the latency of nice 0 tasks unlike SD. New
scheduling class just for X? Sounds like a very complicated
userspace-changing way to just do the equivalent of nice -n -10
obfuscated.
i think you are missing the point. We _do
* Masayuki Nakagawa [EMAIL PROTECTED] wrote:
I found an issue with -rt patch. It is that netstat doesn't show IPv6
sockets in ESTABLISHED state. This issue happens because a flag bit of
ebitmask is not set when the IPv6 socket connection is established.
The fix is to set the flag bit in
* David Howells [EMAIL PROTECTED] wrote:
But short of recording the lock sequence, I don't think there's anyway
to find out for sure. printk probably won't cut it as a recording
mechanism because its overheads are too great.
getting a good trace of it is easy: pick up the latest -rt
with getting a quality scheduling trace anyway.
Ingo
/*
* Copyright (C) 2005, Ingo Molnar [EMAIL PROTECTED]
*
* user-triggered tracing.
*
* The -rt kernel has a built-in kernel tracer, which will trace
* all kernel function calls (and a couple of special events as well),
* by using a build
* Con Kolivas [EMAIL PROTECTED] wrote:
I was more focused on the general case, but all I should have to do
to de-claw all of these sleep exploits is account rr time (only a
couple of lines, done and building now). It's only a couple of
lines.
The more you try to de-claw these
* Ingo Molnar [EMAIL PROTECTED] wrote:
there's a different type of regression now: under high load i dont
get a crash, i get a hung interface instead. No error packets or
other weird interface state - just a hung interface. [...]
the interface stats do not change from that point
* Michal Piotrowski [EMAIL PROTECTED] wrote:
thanks! I have stared at hrtimer.c a few more hours and the good
news is that i found a narrow SMP race. The bad news is that i dont
think it could explain your bug symptoms: the worst-case effect of
the race should be an incorrect timeout
* Linus Torvalds [EMAIL PROTECTED] wrote:
I'd almost prefer to just not add kernel threads to any parent process
list *at*all*.
i think part of the problem is the legacy that the list is artificially
unified: tasks that 'will possibly exit' are on the same list as tasks
that 'have already
* Ingo Molnar [EMAIL PROTECTED] wrote:
putting the freshly reaped tasks at the 'head' of the list is just a
fancy (and incomplete) way of splitting the list up into two lists, and
i'd advocate a clean split. Just like have have split the ptrace_list
* Oleg Nesterov [EMAIL PROTECTED] wrote:
Thinking about it I do agree with Linus that two lists sounds like
the right solution because it ensures we always have O(1) time when
waiting for a zombie.
Well. I bet this will be painful, and will uglify the code even more.
do_wait() has
* Nathan Lynch [EMAIL PROTECTED] wrote:
- raw_notifier_call_chain(cpu_chain, CPU_LOCK_ACQUIRE, hcpu);
+ if (freeze_processes(FE_HOTPLUG_CPU)) {
+ thaw_processes(FE_HOTPLUG_CPU);
+ return -EBUSY;
+ }
+
If I'm understanding correctly, this will cause
#
* John [EMAIL PROTECTED] wrote:
Hello,
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.5
The unified diff is attached to this message.
thanks - this is useful to those who are not that much on the bleeding
edge.
I'd be happy to hear comments on what I've done wrong.
78
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
no. Two _completely separate_ lists.
i.e. a to-be-reaped task will still be on the main list _too_. The
main list is for all the PID semantics rules. The reap-list is just
for wait4() processing
* Davide Libenzi davidel@xmailserver.org wrote:
Ohhh, the signal struct! Funny name for something that nowadays
has probably no more than a 5% affinity with signal-related tasks
:/
Hmm. I wonder if we should just rename it the struct thread_group,
or struct task_group. Those
* Ingo Molnar [EMAIL PROTECTED] wrote:
i.e. a to-be-reaped task will still be on the main list _too_. The
main list is for all the PID semantics rules. The reap-list is
just for wait4() processing. The two would be completely separate.
And what pray tell except for heuristics
: .flags = SA_SHIRQ
so the patch is fine to me:
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
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
* Andrew Morton [EMAIL PROTECTED] wrote:
i've attached an updated version of trace-it.c, which will turn this
off itself, using a sysctl. I also made WAKEUP_TIMING default-off.
ok. http://userweb.kernel.org/~akpm/to-ingo.txt is the trace of
taskset -c 0 ./jakubs-test-app
* Oleg Nesterov [EMAIL PROTECTED] wrote:
I'd almost prefer to just not add kernel threads to any parent
process list *at*all*.
Yes sure, I didn't argue with that. However, -exit_state = -1 does
matter, we can't detach process unless we make it auto-reap.
Off course, we also need to
* Oleg Nesterov [EMAIL PROTECTED] wrote:
Probably it is I who missed something :)
But why can't we do both changes? I think it is just ugly to use init
to reap the kernel thread. Ok, wait4() can find zombie quickly if we
do the -children split. But /sbin/init could be swapped out, we
. The
patch below should fix it. Soeren, can you confirm that you are using a
!CONFIG_SMP kernel, and if yes, does the patch below fix the resume
problem for you?
Ingo
Subject: [patch] high-res timers: UP resume fix
From: Ingo Molnar [EMAIL PROTECTED
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] Soeren, can you confirm that you are using a !CONFIG_SMP kernel,
and if yes, does the patch below fix the resume problem for you?
hm, you seem to have a CONFIG_SMP=y kernel. I dont immediately see where
we re-enable interrupts in the SMP case
* Thomas Gleixner [EMAIL PROTECTED] wrote:
On Sat, 2007-04-07 at 10:25 +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] Soeren, can you confirm that you are using a !CONFIG_SMP kernel,
and if yes, does the patch below fix the resume problem for you?
hm
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
following the conversation on a redundant reschedule call in
set_user_prio(), here is a possible approach.
The patch is somewhat intrusive as it even dares to adapt
TASK_PREEMPTS_CURR().
looks good to me, but the patch seems seriously
* Andrew Morton [EMAIL PROTECTED] wrote:
so
- your code only gets publically tested in its against-staircase
version
- the against-mainline version will get merged without having been
publically tested outside of staircase
which is probably all OK for a 2.6.22-rc1 thing,
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
We do in on_each_cpu() unconditionally. I missed that.
BTW, the on_each_cpu() in clock_was_set() is unnecessary, because
timekeeping_resume() is always run on one CPU.
yes - but that's not the only place where we do clock_was_set(), and the
find updated patch below - only the patch description changed: i removed
the 'UP' thing (patch has relevance on SMP too), and added Thomas' ack.
Ingo
Subject: [patch] high-res timers: resume fix
From: Ingo Molnar [EMAIL PROTECTED]
Soeren Sonnenburg
the timer retrigger only on the current CPU.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Acked-by: Thomas Gleixner [EMAIL PROTECTED]
---
include/linux/hrtimer.h |3 +++
kernel/hrtimer.c| 12
kernel/timer.c |2 +-
3 files changed, 16 insertions(+), 1 deletion
* Gene Heskett [EMAIL PROTECTED] wrote:
To be expected, there are after all, only so many cpu cycles to go
around. Here I sit, running 2.6.21-rc6 ATM, and since there is not an
SD patch that applies cleanly to rc6, I am back to typing half or more
of a sentence blind while I answer a
* Gene Heskett [EMAIL PROTECTED] wrote:
Yes it would be Ingo, but so far, none of the recent -rt patches has
booted on this machine, the last one I tried a few days ago failing to
find /dev/root, whatever the heck that is.
did you have a chance to try the yum kernel by any chance? The
* Linux Kernel Mailing List linux-kernel@vger.kernel.org wrote:
Committer: Linus Torvalds [EMAIL PROTECTED]
CommitDate: Sat Apr 7 10:18:33 2007 -0700
sched.c: Remove unused variable 'relative'
Getting rid of the p-children printout in show_task() left behind an
unused
* Gene Heskett [EMAIL PROTECTED] wrote:
That said, I am booted to the patch you sent me now, and this also is
a very obvious improvement, one I could easily live with on a long
term basis. I haven't tried a kernel build in the background yet, but
I have sat here and played patience for
* Ingo Molnar [EMAIL PROTECTED] wrote:
My question then, is why did it take a very public cat-fight to get
this looked at and the code adjusted? Its been what, nearly 2 years
since Linus himself made a comment that this thing needed fixed.
The fixes then done were of very little
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 6 Apr 2007, Davide Libenzi wrote:
or lets just face it and name it what it is: process_struct ;-)
That'd be fine too! Wonder if Linus would swallow a rename patch like
that...
I don't really see the point. It's not even *true*.
, and it was in fact acked
by Con too:
Signed-off-by: Mike Galbraith [EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Cc: Nick Piggin [EMAIL PROTECTED]
Acked-by: Con Kolivas [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL
* Rene Herman [EMAIL PROTECTED] wrote:
To me, the example rather serves as confirmation of what Kolivas has
been saying; endlessly tweaking the tweaks isn't going anywhere.
but ... SD clearly regresses in some areas, so by that logic SD isnt
going anywhere either?
note that i still like
), but this feature isn't important
enough to justify the churn.
Cc: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/block/genhd.c b/block/genhd.c
index 050a1f0..441432a 100644
--- a/block
* Rene Herman [EMAIL PROTECTED] wrote:
- the code actually has to match that stated goal. Right now it
diverges from it (it is not a fair scheduler), and it's not
clear why.
I read most of the discussion centering around that specific point as
well, and frankly, I mostly came
* Gene Heskett [EMAIL PROTECTED] wrote:
Andrew has already sent a revert patch to Linus and it's in -rc6.
The commit is below.
Is this not the patch that reverts it? I want the patch that put it
in, because that will be a one time churn and be done with it,
hopefully for good. [...]
* William Lee Irwin III [EMAIL PROTECTED] wrote:
I strongly suggest assembling a battery of cleanly and properly
written, configurable testcases, and scripting a series of regression
tests as opposed to just randomly running kernel compiles and relying
on Braille.
there's interbench,
PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
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://www.tux.org/lkml/
* Andrew Morton [EMAIL PROTECTED] wrote:
-static DEFINE_PER_CPU(struct rq, runqueues);
+static DEFINE_PER_CPU(struct rq, runqueues) cacheline_aligned_in_smp;
Remember that this can consume up to (linesize-4 * NR_CPUS) bytes,
which is rather a lot.
yes - but one (special) issue here
* Russell King [EMAIL PROTECTED] wrote:
One per PC card socket to avoid the sysfs locking crappyness that
would otherwise deadlock, and to convert from the old unreadable state
machine implementation to a much more readable linearly coded
implementation.
Could probably be eliminated if
meawhile (in a different way) so no need to do any change there.
Ingo
---
Subject: [patch] net/xfrm: fix audit logging
From: Ingo Molnar [EMAIL PROTECTED]
i got the following crash when restarting a (timed out) ipsec session
on 2.6.20-rc1:
BUG: unable to handle kernel NULL
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
no. Two _completely separate_ lists.
i.e. a to-be-reaped task will still be on the main list _too_. The
main list is for all the PID semantics rules. The reap-list is just
for wait4() processing
601 - 700 of 32618 matches
Mail list logo
