When did /proc/self get changed to follow tgid instead of pid? glibc uses
/proc/self to refer to various things that are usually shared anyway (fd,
maps, cwd, exe), but I think the expectation has always been that this
refers to the same calling thread, not the group leader. e.g., if one
thread
* Thomas Gleixner [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
and send us the output? (Enabling CONFIG_TIMER_STATS,
CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS would maximize the amount
of information.)
This
Ingo Molnar [EMAIL PROTECTED] writes:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 2 Nov 2007, Dave Hansen wrote:
There are certainly more of these, but here is one In the futex
userspace address, we install the current pid's vnr into a userspace
address.
Now, realistically,
On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
Current implemenations use userspace-libraries. In userspace you e.g.
can't
easily protect the uniquness of a UUID against other running _processes_.
If you try do, you'll need to do locking e.g. with shared memory, which
On 11/21/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i guess it was a v2.6.24 change, hence a regression that needs to be
fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux 2.6.0-test6
--
Guillaume
-
To unsubscribe from this list:
good evening,
i stumbled over some funny issue when trying windirstat (like KDirStat) with
wine.
after running that tool for a while my system rebooted. i could reproduce this
with every run.
after some deep investigation (i thought i had stability issues with my system
and spent more than
On Tue, 20 Nov 2007, Roland McGrath wrote:
rename arch/x86/{kernel/vsyscall-int80_32.S = vdso/vdso32/int80.S} (97%)
rename arch/x86/{kernel/vsyscall-note_32.S = vdso/vdso32/note.S} (95%)
rename arch/x86/{kernel/vsyscall-sigreturn_32.S =
vdso/vdso32/sigreturn.S} (100%)
rename
On Wed, 2007-11-21 at 09:39 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote:
We're talking about trying to fix this for 2.4; which is already at
-rc3 ... Is an entire arch change for dma alignment really a merge
candidate at this stage?
On Tuesday 20 November 2007, Matt Mackall wrote:
On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
Current implemenations use userspace-libraries. In userspace you e.g.
can't
easily protect the uniquness of a UUID against other running
_processes_.
If you try
From: Ingo Molnar [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 22:49:27 +0100
* Greg KH [EMAIL PROTECTED] wrote:
On Tue, Nov 20, 2007 at 09:39:19PM +0100, Ingo Molnar wrote:
* Greg KH [EMAIL PROTECTED] wrote:
but we only have cpu_clock() from v2.6.23 onwards - so we should not
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 15:02:43 -0500
Mark Lord [EMAIL PROTECTED] wrote:
..
Well, for my dualCore notebook, dualCore MythTV box, and QuadCore
desktop, the behaviour of the existing, working, 32-bit kernel
IRQBALANCE code outperforms the userspace utility.
Mostly, I
On Fri, 02 Nov 2007 12:10:00 -0500 Jordan Russell [EMAIL PROTECTED] wrote:
Hi,
With 2.6.23.1 (stock and Fedora), roughly 50% of the time my system
hangs indefinitely during the kernel boot process. The hangs occur in
places where normally a brief delay is seen, such as when detecting
serial
Ingo Molnar wrote:
* Arjan van de Ven [EMAIL PROTECTED] wrote:
kernel or kernel source? If there was a good place in the kernel
source I'd not be against moving irqbalance there. [...]
would this be a good case study to use klibc and start up irqbalanced
automatically? I'd love it if we
Oh, it seems it has indeed been that way for a very long time, so I was
mistaken. It still seems a little odd to me. Ulrich can say definitively
whether the kind of concern I mentioned really matters one way or the other
for glibc.
Thanks,
Roland
-
To unsubscribe from this list: send the line
Ingo Molnar wrote:
do you suggest that extending the system call calling convention to
include an arbitrary number of parameters will solve all these API needs
we have at the moment?
if yes, then a one-shot syslet/async call would in essence be:
syslet_arg1 ... N, syscall_arg 1 ... M
* David Miller [EMAIL PROTECTED] wrote:
so just to reiterate, to make sure we have the same plans: lets
leave v2.6.22 and earlier kernels alone - and lets strive for the
latest patches and code for v2.6.23 (and v2.6.24, evidently).
I've validated that those patches make 2.6.23 behave
git format-patch -p
does the trick at least here :)
Ok, I can use that in future. I hope it still means that in the eventual
merged state, GIT will be aware of all the renames.
Thanks,
Roland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
* Mark Lord [EMAIL PROTECTED] wrote:
Perhaps, but this also violates the principle that the kernel should
just *work* with sensible defaults. I don't use an initrd, or an
initramfs, and have no intention of ever doing so.
nor do i - i was under the impression that klibc was able to work
Petr Baudis wrote, On 11/20/2007 10:59 PM:
Hi,
On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
I see gitweb is much more usable (faster) than a few months ago, but
there is one thing a bit problematic: in the history of patches I'm
very often interested in which kernel
On Wednesday 21 November 2007, Theodore Tso wrote:
On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
Even with a futex? Or userspace atomics?
Yes, you'll need a futex or similiar.
The problem is then more, where will you put that futex to be able
to protect against
Mark Lord wrote:
Perhaps, but this also violates the principle that the kernel
should just *work* with sensible defaults. I don't use an initrd,
or an initramfs, and have no intention of ever doing so.
I *like* having a single boot image with no unneeded/unwanted complexity.
It's only
[EMAIL PROTECTED] wrote:
good evening,
i stumbled over some funny issue when trying windirstat (like KDirStat) with
wine.
after running that tool for a while my system rebooted. i could reproduce this
with every run.
after some deep investigation (i thought i had stability issues with my
On Wed, Nov 21, 2007 at 12:11:57AM +0100, Helge Deller wrote:
On Tuesday 20 November 2007, Matt Mackall wrote:
On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
Current implemenations use userspace-libraries. In userspace you e.g.
can't
easily protect the uniquness
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland McGrath wrote:
Oh, it seems it has indeed been that way for a very long time, so I was
mistaken. It still seems a little odd to me. Ulrich can say definitively
whether the kind of concern I mentioned really matters one way or the other
On Tue, Nov 20, 2007 at 03:49:43AM -0700, Jan Beulich wrote:
This patch (in its incarnation in our SLE10SP2 tree) is causing resource
allocation failures on one of my machines.
Does the latest 2.6.23 kernel also cause these same problems?
The condition for this is that besides ROMs behind a
On Tue, Nov 20, 2007 at 03:40:30PM +0100, Milan Broz wrote:
(Note comment in code It is permissible to free the struct
work_struct from inside the function that is called from it.)
I don't understand yet how lockdep behaves if the work struct gets
reused and the reused one finishes first.
I
Ingo Molnar wrote:
* Mark Lord [EMAIL PROTECTED] wrote:
Perhaps, but this also violates the principle that the kernel should
just *work* with sensible defaults. I don't use an initrd, or an
initramfs, and have no intention of ever doing so.
nor do i - i was under the impression that klibc
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Why not just pin down the current ABI that there's 6 syscall
parameters _and not more_?
Because we have already violated it. There are system calls that need
more than 6 arguments: we need *a* convention. Worse, we're not
actually talking 6
On Tuesday, 20 of November 2007, Huang, Ying wrote:
On Tue, 2007-11-20 at 03:24 +0100, Rafael J. Wysocki wrote:
On Tuesday, 20 of November 2007, Huang, Ying wrote:
On Mon, 2007-11-19 at 19:22 +0100, Rafael J. Wysocki wrote:
+#ifdef CONFIG_KEXEC
+static void
On Tuesday, 20 of November 2007, Alan Stern wrote:
On Tue, 20 Nov 2007, Huang, Ying wrote:
- What is the difference between PMSG_SUSPEND and PMSG_FREEZE?
SUSPEND means that the system is about to go into a low-power state, so
the driver should take the appropriate action to reduce the
On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
Hi all:
* Alan Stern [EMAIL PROTECTED] [2007-11-19 15:27:14 -0500]:
On Mon, 19 Nov 2007, Rudolf Marek wrote:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems
* Guillaume Chazarain [EMAIL PROTECTED] wrote:
On 11/21/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i guess it was a v2.6.24 change, hence a regression that needs to be
fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux
* Ulrich Drepper [EMAIL PROTECTED] wrote:
Oh, it seems it has indeed been that way for a very long time, so I
was mistaken. It still seems a little odd to me. Ulrich can say
definitively whether the kind of concern I mentioned really matters
one way or the other for glibc.
glibc
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Mark Lord [EMAIL PROTECTED] wrote:
Perhaps, but this also violates the principle that the kernel should just
*work* with sensible defaults. I don't use an initrd, or an initramfs,
and have no intention of ever doing so.
Jochen Friedrich wrote:
PORTA and PORTB have odr registers, as well. However, the PORTB odr
register is only 16bit.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
Acked-by: Scott Wood [EMAIL PROTECTED]
BTW, you may want to send the patches to linuxppc-dev rather than
linuxppc-embedded...
On Wed, Nov 07, 2007 at 04:32:00PM +, Phillip Lougher wrote:
maximilian attems wrote:
On Mon, Nov 05, 2007 at 11:13:14AM +, Phillip Lougher wrote:
The next stage after this release is to fix the one remaining blocking
issue
(filesystem endianness), and then try to get
can you see any danger to providing a /proc/self_task/ link? (or can you
think of a better name/API/approach)
That is a poor name to choose given /proc/self/task exists as something
else (just try writing a sentence comparing them and then read it aloud).
Probably /proc/self/task/self is what
On Wed, Nov 21, 2007 at 12:06:57AM +0100, [EMAIL PROTECTED] wrote:
- be root
That's your first mistake.
- cat /dev/watchdog or dd if=/dev/watchdog of=/dev/zero bs=1 count=1 or .
- wait one minute
*reboot*!
And that's the defined behavior of /dev/watchdog, yes. Many years too
On Tue, 20 Nov 2007, Roland McGrath wrote:
git format-patch -p
does the trick at least here :)
Ok, I can use that in future. I hope it still means that in the eventual
merged state, GIT will be aware of all the renames.
git does not store the renamed/copied info at all. That's just
Joe Perches [EMAIL PROTECTED] writes:
--- a/drivers/net/wan/wanxl.c
+++ b/drivers/net/wan/wanxl.c
@@ -743,7 +743,7 @@ static int __devinit wanxl_pci_init_one(struct pci_dev
*pdev,
}while (time_after(timeout, jiffies));
if (!stat) {
- printk(KERN_WARNING wanXL
On Tue, Nov 20, 2007 at 03:15:38PM -0800, David Miller wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 22:49:27 +0100
* Greg KH [EMAIL PROTECTED] wrote:
On Tue, Nov 20, 2007 at 09:39:19PM +0100, Ingo Molnar wrote:
* Greg KH [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Mark Lord [EMAIL PROTECTED] wrote:
Perhaps, but this also violates the principle that the kernel should just
*work* with sensible defaults. I don't use an initrd, or an initramfs,
and have no intention of
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Why not just pin down the current ABI that there's 6 syscall
parameters _and not more_?
Because we have already violated it. There are system calls that need
more than 6 arguments: we need *a* convention. Worse, we're not
There is.. it's called root privileges.
yes, true.
but - regardless of being a windows app or not - what if you want to take a
look on your system as a whole, especially when using some tool which
graphically shows how and where your diskspace is being used? if i let this
run from ordinary
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
This changes the 64-bit kernel's support for the 32-bit sysenter
instruction to use stored fields rather than constants for the
user-mode return address, as the 32-bit kernel does. This adds a
sysenter_return field to struct
Is there any other information that I can provide which might help in
resolving this bug?
On 11/18/07, Raymano Garibaldi [EMAIL PROTECTED] wrote:
The last time I tried this and it worked was 2.6.21. Below is a
portion of the kernel log file where I had a USB storage device
attached to the
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Nope. It runs inside an initramfs, of course; that initramfs is
linked into the kernel binary.
would be nice to have a single-image variant for all of this. having
the separate initrd was always trouble - and it's pointless as well.
(we rarely
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
This makes x86_64's ia32 emulation support share the sources used in the
32-bit kernel for the 32-bit vDSO and much of its setup code.
The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
The abi.syscall32 sysctl
On Tue, 20 Nov 2007, Christoph Lameter wrote:
32bit sign extension for what? Absolute data references? The addressing
that I have seen was IP relative. Thus I thought that the kernel could be
moved lower.
Argh. This is all depending on a special gcc option to compile the
kernel and that
* Zachary Amsden [EMAIL PROTECTED] wrote:
The 32-bit vDSO mapping now behaves the same on x86_64 as on native
32-bit. The abi.syscall32 sysctl on x86_64 now takes the same values
that vm.vdso_enabled takes on the 32-bit kernel. That is, 1 means a
randomized vDSO location, 2 means the
I think you should drop CONFIG_COMPAT_VDSO support for 32-bit VDSO on
64-bit kernel. This was only to hack around a broken version of glibc
that shipped with SUSE PRO 9.0,
I would be severly opposed to that. You cannot break compatibility to a large
chunk of userland. You would also break
On Tue, 20 Nov 2007 23:58:38 +0100
Helge Deller [EMAIL PROTECTED] wrote:
David Schwartz wrote:
Any UUID generator that can produce duplicate UUIDs with probability
significantly less than purely random UUIDs is so badly broken that it
should not ever be used. Anyone who finds such a UUID
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Nope. It runs inside an initramfs, of course; that initramfs is
linked into the kernel binary.
would be nice to have a single-image variant for all of this. having
the separate initrd was always trouble - and it's pointless as
On Tuesday, 20 of November 2007, Ingo Molnar wrote:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't
changed the non-functioning of 2.6.24-rc3
s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from
console
For 64-bit, the hack consists of a switch that chooses whether to use a
fixed address or a generically-assigned one, that's all there is to it.
So it costs about nothing.
Even for 32-bit, CONFIG_COMPAT_VDSO for a while now is doing nothing but
changing the default of the sysctl variable. There
@@ -104,7 +103,7 @@ ENTRY(ia32_sysenter_target)
pushfq
CFI_ADJUST_CFA_OFFSET 8
/*CFI_REL_OFFSET rflags,0*/
- movl$VSYSCALL32_SYSEXIT, %r10d
+ movl8*3-THREAD_SIZE+threadinfo_sysenter_return(%rsp), %r10d
8*3-THREAD_SIZE is not very intuitive. Can you add a
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Nope. It runs inside an initramfs, of course; that initramfs is linked
into the kernel binary.
would be nice to have a single-image variant for all of this. having the
separate initrd
This release brings the number of zonelists to two instead of one. Getting
all the corner cases right for __GFP_THISNODE and one zonelist was turning
into a complicated mess. Not only was it affecting too many paths but it
reached the point where it should be reviewed as a standalone change.
Much
This release brings the number of zonelists to two instead of one. Getting
all the corner cases right for __GFP_THISNODE and one zonelist was turning
into a complicated mess. Not only was it affecting too many paths but it
reached the point where it should be reviewed as a standalone change.
Much
The allocator deals with zonelists which indicate the order in which zones
should be targeted for an allocation. Similarly, direct reclaim of pages
iterates over an array of zones. For consistency, this patch converts direct
reclaim to use a zonelist. No functionality is changed by this patch.
This patch introduces a node_zonelist() helper function. It is used to lookup
the appropriate zonelist given a node and a GFP mask. The patch on its own is
a cleanup but it helps clarify parts of the one-zonelist-per-node patchset. If
necessary, it can be merged with the next patch in this set
On NUMA, zone_statistics() is used to record events like numa hit, miss
and foreign. It assumes that the first zone in a zonelist is the preferred
zone. When multiple zonelists are replaced by one that is filtered, this
is no longer the case.
This patch records what the preferred zone is rather
Currently a node has two sets of zonelists, one for each zone type in the
system and a second set for GFP_THISNODE allocations. Based on the zones
allowed by a gfp mask, one of these zonelists is selected. All of these
zonelists consume memory and occupy cache lines.
This patch replaces the
Filtering zonelists requires very frequent use of zone_idx(). This is costly
as it involves a lookup of another structure and a substraction operation. As
the zone_idx is often required, it should be quickly accessible. The node
idx could also be stored here if it was found that accessing
The MPOL_BIND policy creates a zonelist that is used for allocations belonging
to that thread that can use the policy_zone. As the per-node zonelist is
already being filtered based on a zone id, this patch adds a version of
__alloc_pages() that takes a nodemask for further filtering. This
On Wednesday, 21 of November 2007, Roland McGrath wrote:
can you see any danger to providing a /proc/self_task/ link? (or can you
think of a better name/API/approach)
That is a poor name to choose given /proc/self/task exists as something
else (just try writing a sentence comparing them
Ulrich Drepper [EMAIL PROTECTED] writes:
Roland McGrath wrote:
Oh, it seems it has indeed been that way for a very long time, so I was
mistaken. It still seems a little odd to me. Ulrich can say definitively
whether the kind of concern I mentioned really matters one way or the other
for
I've had other freezes before but this was the first time I was able
to see what was actually going on.
IRQ 21 appears to be shared between sata_nv and ethernet.
Does this mean my hardware/BIOS is broken somehow?
Not neccessarily. It could a bug in one of the drivers using IRQ 21
(sata_nv
Roland McGrath [EMAIL PROTECTED] writes:
can you see any danger to providing a /proc/self_task/ link? (or can you
think of a better name/API/approach)
That is a poor name to choose given /proc/self/task exists as something
else (just try writing a sentence comparing them and then read it
Ingo Molnar wrote:
i took that Nope as referring to my impression - but you in fact meant
that i am not wrong? :-) So nothing to see here. single-bzImage initrd
was and is possible, so we could in fact move chunks of system-related
userland (such as irqbalanced) into the kernel proper?
On Tue, 20 Nov 2007 16:51:21 -0600
Serge E. Hallyn [EMAIL PROTECTED] wrote:
Quoting Chris Friedhoff ([EMAIL PROTECTED]):
On Tue, 20 Nov 2007 08:51:06 -0600
Serge E. Hallyn [EMAIL PROTECTED] wrote:
Quoting Chris Friedhoff ([EMAIL PROTECTED]):
On Mon, 19 Nov 2007 17:16:44 -0600
* Trond Myklebust ([EMAIL PROTECTED]) wrote:
On Tue, 2007-11-20 at 16:50 -0500, Mathieu Desnoyers wrote:
Then my original point is valid : put_no_resched() will cause unwanted
scheduler latencies. It's designed only to be used from within the
scheduler code itself. The correct approach
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer are allocated so that
they don't get allocated above 4GB and break legacy mode (which is
Tejun Heo wrote:
Tejun Heo wrote:
If so, can you please add that switching into register mode is okay as
long as there's no other ADMA commands in flight and add
WARN_ON((qc-flags ATA_QCFLAG_RESULT_TF) link-sactive)?
More accurately, link-sactive test can be substituted with
[
Changes since V3:
Updated to git tree 2ffbb8377c7a0713baf6644e285adc27a5654582
Removed cpumask_t from stacks (using per_cpu masks).
Optimized the searching for overloaded queues a bit.
(a lot of work in this area)
Run RT balance logic on waking of new tasks.
The
From: Gregory Haskins [EMAIL PROTECTED]
We can cheaply track the number of bits set in the cpumask for the lowest
priority CPUs. Therefore, compute the mask's weight and use it to skip
the optimal domain search logic when there is only one CPU available.
Signed-off-by: Gregory Haskins [EMAIL
This patch adds an RT overload accounting system. When a runqueue has
more than one RT task queued, it is marked as overloaded. That is that it
is a candidate to have RT tasks pulled from it.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched_rt.c | 36
This patch adds accounting to each runqueue to keep track of the
highest prio task queued on the run queue. We only care about
RT tasks, so if the run queue does not contain any active RT tasks
its priority will be considered MAX_RT_PRIO.
This information will be used for later patches.
This patch changes the searching for a run queue by a waking RT task
to try to pick another runqueue if the currently running task
is an RT task.
The reason is that RT tasks behave different than normal
tasks. Preempting a normal task to run a RT task to keep
its cache hot is fine, because the
This patch adds pushing of overloaded RT tasks from a runqueue that is
having tasks (most likely RT tasks) added to the run queue.
TODO: We don't cover the case of waking of new RT tasks (yet).
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched.c|3 +++
kernel/sched_rt.c
From: Gregory Haskins [EMAIL PROTECTED]
In the original patch series that Steven Rostedt and I worked on together,
we both took different approaches to low-priority wakeup path. I utilized
pre-routing (push the task away to a less important RQ before activating)
approach, while Steve utilized a
From: Gregory Haskins [EMAIL PROTECTED]
this_rq is normally used to denote the RQ on the current cpu
(i.e. cpu_rq(this_cpu)). So clean up the usage of this_rq to be
more consistent with the rest of the code.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL
Run the RT balancing code on wake up to an RT task.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched.c |1 +
1 file changed, 1 insertion(+)
Index: linux-compile.git/kernel/sched.c
===
---
From: Gregory Haskins [EMAIL PROTECTED]
Isolate the search logic into a function so that it can be used later
in places other than find_locked_lowest_rq().
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched_rt.c | 66
This patch adds an algorithm to push extra RT tasks off a run queue to
other CPU runqueues.
When more than one RT task is added to a run queue, this algorithm takes
an assertive approach to push the RT tasks that are not running onto other
run queues that have lower priority. The way this works
From: Gregory Haskins [EMAIL PROTECTED]
We have logic to detect whether the system has migratable tasks, but we are
not using it when deciding whether to push tasks away. So we add support
for considering this new information.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
Signed-off-by:
From: Gregory Haskins [EMAIL PROTECTED]
The current wake-up code path tries to determine if it can optimize the
wake-up to this_cpu by computing load calculations. The problem is that
these calculations are only relevant to CFS tasks where load is king. For RT
tasks, priority is king. So the
From: Gregory Haskins [EMAIL PROTECTED]
Some RT tasks (particularly kthreads) are bound to one specific CPU.
It is fairly common for two or more bound tasks to get queued up at the
same time. Consider, for instance, softirq_timer and softirq_sched. A
timer goes off in an ISR which schedules
From: Gregory Haskins [EMAIL PROTECTED]
The current code base assumes a relatively flat CPU/core topology and will
route RT tasks to any CPU fairly equally. In the real world, there are
various toplogies and affinities that govern where a task is best suited to
run with the smallest amount of
From: Gregory Haskins [EMAIL PROTECTED]
We don't need to bother searching if the task cannot be migrated
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched_rt.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
From: Gregory Haskins [EMAIL PROTECTED]
It doesn't hurt if we allow the current CPU to be included in the
search. We will just simply skip it later if the current CPU turns out
to be the lowest.
We will use this later in the series
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
This patch adds accounting to keep track of the number of RT tasks running
on a runqueue. This information will be used in later patches.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched.c|1 +
kernel/sched_rt.c | 17 +
2 files changed, 18 insertions(+)
This patch adds the algorithm to pull tasks from RT overloaded runqueues.
When a pull RT is initiated, all overloaded runqueues are examined for
a RT task that is higher in prio than the highest prio task queued on the
target runqueue. If another runqueue holds a RT task that is of higher
prio
This patch removes several cpumask operations by keeping track
of the first of the CPUS that is of the lowest priority. When
the search for the lowest priority runqueue is completed, all
the bits up to the first CPU with the lowest priority runqueue
is cleared.
Signed-off-by: Steven Rostedt
Since we now take an active approach to load balancing, we don't need to
balance RT tasks via CFS. In fact, this code was found to pull RT tasks
away from CPUS that the active movement performed, resulting in
large latencies.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched_rt.c
On Monday, 19 of November 2007, Franck Bui-Huu wrote:
Rafael J. Wysocki wrote:
On Sunday, 18 of November 2007, Franck Bui-Huu wrote:
Rafael J. Wysocki wrote:
See the call to wait_even() made by apm_ioctl(). If any processes
run this, it will prevent the system to suspend...
True, but
But one can subtract too... Hmmm... So the cpu area 0 could be put at
the beginning of the 2GB kernel area and then grow downwards from
0x8000. The cost in terms of code is one subtract
instruction for each per_cpu() or CPU_PTR()
The next thing doward from 0x8000 is the
Pavel Emelyanov [EMAIL PROTECTED] writes:
Rafael J. Wysocki wrote:
On Monday, 19 of November 2007, Pavel Machek wrote:
Hi!
I think that this worked before:
[EMAIL PROTECTED]:/proc# find . -name timer_info
find: WARNING: Hard link count is wrong for ./net: this may be a bug
in your
Eric W. Biederman wrote:
Could you elaborate a bit on how the semantics of returning the
wrong information are more useful?
In particular if a thread does the logical equivalent of:
grep Pid: /proc/self/status. It always get the tgid despite
having a different process id.
The POSIX-defined
From: Cyrill Gorcunov [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 20:28:33 +0300
From: Cyrill Gorcunov [EMAIL PROTECTED]
This patch adds checking for possible NULL pointer dereference
if of_find_property() failed.
Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
Applied, thanks.
-
To
401 - 500 of 1146 matches
Mail list logo
