Nick wrote:
Sorry for the confusion: I only meant the sched.c part of that
patch, not the full thing.
Ah - ok. We're getting closer then. Good.
Let me be sure I've got this right then.
You prefer the interface from your proposed patch, by which the
cpuset code passes sched domain requests
* Ingo Molnar [EMAIL PROTECTED] wrote:
-CONFIG_MAC80211_DEBUGFS=y
it's CONFIG_MAC80211_DEBUGFS=y causing the crash.
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
Thanks Randy!
update patch below.
---
Subject: lockstat: documentation
Provide some documentation for CONFIG_LOCK_STAT
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
Documentation/lockstat.txt | 120 +
lib/Kconfig.debug |2
2
* Paul Jackson [EMAIL PROTECTED] wrote:
There might be an even simpler way. If the kernel/sched.c routines
detach_destroy_domains() and build_sched_domains() were exposed as
external routines, then the cpuset code could call them directly,
removing the partition_sched_domains() routine
On Tuesday 02 October 2007, Jens Axboe wrote:
Hi Arnd,
Updated patch below. I kept the code in compat_ioctl.c, to me it seems
like the cleanest approach. I need the BLKTRACESETUP32 define both in
compat_ioctl.c and blktrace.c if I move it, and I need to hard-core the
struct size or define
* Peter Zijlstra [EMAIL PROTECTED] wrote:
Thanks Randy!
update patch below.
---
Subject: lockstat: documentation
Provide some documentation for CONFIG_LOCK_STAT
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Ingo
-
To unsubscribe
in any case i'd like to see the externally visible API get in foremost -
and there now seems to be agreement about that. (yay!) Any internal
shaping of APIs can be done flexibly between cpusets and the scheduler.
Yup - though Nick and I will have to agree to -some- internal interface
between
Hi guys
Would it not be clearer to #include asm/bootparam.h and use
the relevant named members of struct setup_header / struct boot_params
rather than the hard-coded values 0x202, 0x1F1, 0x214 ?
--
Chris
On Wed, 2007-10-03 at 09:40 +1000, Rusty Russell wrote:
[snip]
+ u8 hdr[1024];
+
On Wed, Oct 03, 2007 at 11:10:58AM +0200, Ingo Molnar wrote:
* Jarek Poplawski [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 10:16:13AM +0200, Ingo Molnar wrote:
* Jarek Poplawski [EMAIL PROTECTED] wrote:
firstly, there's no notion of timeslices in CFS. (in CFS tasks
Yeah -- cpusets are hierarchical. And some of the use cases for
which cpusets are designed are hierarchical.
But partitioning isn't.
Yup. We've got a square peg and a round hole. An impedance mismatch.
That's the root cause of this entire wibbling session, in my view.
The essential
On Wednesday 03 October 2007 19:21, Paul Jackson wrote:
Nick wrote:
Sorry for the confusion: I only meant the sched.c part of that
patch, not the full thing.
Ah - ok. We're getting closer then. Good.
Let me be sure I've got this right then.
You prefer the interface from your proposed
Hi Ingo,
Em Qua, 2007-10-03 às 09:08 +0200, Ingo Molnar escreveu:
FYI, there are 7 V4L drivers that produce this (non-fatal) warning:
Those warnings are inoffensive ;) V4L core does provide a generic
release callback. Anyway, we'll take a look on it and fix, to avoid the
warnings.
[
Seen this a few times lately on a machine running rawhide when running
screen (and doing something, it's not automatic. And box works just fine).
I think I saw this a few weeks back, so it's not a new regression.
=
[ INFO: possible recursive locking
Nick, responding to pj, wrote:
However a little bit of additional kernel cpuset code could hide
this detail from user space, by recognizing when the user had
asked to turn off load balancing on some larger cpuset, and by
then calling partition_sched_domains() multiple
On Wednesday 03 October 2007 19:39, Paul Jackson wrote:
in any case i'd like to see the externally visible API get in foremost -
and there now seems to be agreement about that. (yay!) Any internal
shaping of APIs can be done flexibly between cpusets and the scheduler.
Yup - though Nick and
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
How about adding this information to the tree then, instead of
creating a new top-level hack, just because something that
On Tuesday 02 October 2007 07:22, Andrew Morton wrote:
remove-zero_page.patch
Linus dislikes it. Probably drop it.
I don't know if Linus actually disliked the patch itself, or disliked
my (maybe confusingly worded) rationale?
To clarify: it is not zero_page that fundamentally causes a
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
How about adding this information to the tree then, instead of
Hi,
The below patch fixes a lockdep error in 2.6.23-rc9 when using tcp_probe.
---
Subject: lockdep: annotate kprobes irq fiddling
kprobes disables irqs for jprobes, but does not tell lockdep about it.
CC: Prasanna S Panchamukhi [EMAIL PROTECTED]
CC: Ananth N Mavinakayanahalli [EMAIL
On Wednesday 03 October 2007 19:55, Paul Jackson wrote:
Yeah -- cpusets are hierarchical. And some of the use cases for
which cpusets are designed are hierarchical.
But partitioning isn't.
Yup. We've got a square peg and a round hole. An impedance mismatch.
That's the root cause of
On Sat 2007-09-15 08:27:23, Anton Altaparmakov wrote:
Hi,
Mark Smith reported a OOM condition when he copies a
large (46GiB) file from an NTFS partition (using the
stock kernel driver) to /dev/ null (or to a file on
ext3, same result).
The machine this runs on has an i386 kernel with
* Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi,
The below patch fixes a lockdep error in 2.6.23-rc9 when using
tcp_probe.
---
Subject: lockdep: annotate kprobes irq fiddling
kprobes disables irqs for jprobes, but does not tell lockdep about it.
this resolves this warning during an
* Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
Hi Ingo,
Em Qua, 2007-10-03 às 09:08 +0200, Ingo Molnar escreveu:
FYI, there are 7 V4L drivers that produce this (non-fatal) warning:
Those warnings are inoffensive ;) V4L core does provide a generic
release callback. Anyway, we'll take
On 03/10/2007, Jarek Poplawski [EMAIL PROTECTED] wrote:
I can't see anything about clearing. I think, this was about charging,
which should change the key enough, to move a task to, maybe, a better
place in a que (tree) than with current ways.
just a quick patch, not tested and I've not
On Wed, 3 Oct 2007 00:00:58 -0700 Paul Jackson [EMAIL PROTECTED] wrote:
Nick wrote:
If code isn't ready to go, it doesn't need to rush, it can just be untangled
or fixed properly etc.
It's close enough for an rc1.
True ... though we seem to be going in circles now. I doubt
taking longer
On Mon, Oct 01, 2007 at 01:10:59PM +0100, veerasena reddy wrote:
Is there any problem if we use the below API's in
linxu-2.6.18
- dma_cache_wback_inv()
- dma_cache_wback()
- dma_cache_inv()
functionality wise, especially in r4k.c i dont see any
difference between the
On 03/10/2007, Dmitry Adamushko [EMAIL PROTECTED] wrote:
On 03/10/2007, Jarek Poplawski [EMAIL PROTECTED] wrote:
I can't see anything about clearing. I think, this was about charging,
which should change the key enough, to move a task to, maybe, a better
place in a que (tree) than with
On Wed, 3 Oct 2007 03:45:09 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
mm-use-pagevec-to-rotate-reclaimable-page.patch
mm-use-pagevec-to-rotate-reclaimable-page-fix.patch
mm-use-pagevec-to-rotate-reclaimable-page-fix-2.patch
--- Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
lib-make-percpu_counter_add-take-s64.patch
--- Fengguang Wu [EMAIL PROTECTED] wrote:
Andrew,
The following patches fix the sluggish writeback behavior.
They are well understood and well tested - but not yet widely tested.
The first patch reverts the debugging -mm only
check_dirty_inode_list.patch -
which is no longer necessary.
Hello.
James Morris wrote:
Would you please explain why you need another level of memory allocation?
What does it do apart from let you check for memory leaks?
Difference between tmy_alloc() and kmalloc() are
tmy_alloc() allows administrator know how much memory is used by TOMOYO
Linux
On Wed, Oct 03, 2007 at 12:58:26PM +0200, Dmitry Adamushko wrote:
On 03/10/2007, Dmitry Adamushko [EMAIL PROTECTED] wrote:
On 03/10/2007, Jarek Poplawski [EMAIL PROTECTED] wrote:
I can't see anything about clearing. I think, this was about charging,
which should change the key enough, to
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
+ se-vruntime += delta_exec_weighted;
thanks Dmitry.
Btw., this is quite similar to the yield_granularity patch i did
originally, just less flexible. It turned out that apps want either zero
granularity or infinite
Hi,
sane is not able to detect my old SCSI scanner with kernel 2.6.23-rc9. The
scanner was found with 2.6.22.8. According to strace the behavior of the
SG_GET_SCSI_ID ioctl changed:
2.6.22.8:
open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
ioctl(3,
Hello.
YOSHIFUJI Hideaki wrote:
Introducing your own list is not good.
Please use hlist or introduce new slist.
James Morris wrote:
You're introducing a custom API, which is open-coded repeatedly throughout
your module.
All linked lists (at least, new ones) must use the standard kernel
On Tue, Oct 02, 2007 at 05:20:03PM -0500, Matt Mackall wrote:
In lib/pagewalk.c, I've been using the various forms of
{pgd,pud,pmd}_none_or_clear_bad while walking page tables as that
seemed the canonical way to do things. Lately (eg with -rc7-mm1),
these have been triggering messages like bad
On Tue, 2 Oct 2007, Jan Engelhardt wrote:
On Oct 2 2007 23:49, Jimmy wrote:
Anyway, I've been trying to figure out what purpose the gpl-only code serves.
What good comes out of disabling people from probing modules that do not
have a
gpl-compatible license?
find /lib/modules/`uname -r`
David Schwartz wrote:
* Jarek Poplawski [EMAIL PROTECTED] wrote:
BTW, it looks like risky to criticise sched_yield too much: some
people can misinterpret such discussions and stop using this at all,
even where it's right.
Really, i have never seen a _single_ mainstream app
On Wed, Oct 03, 2007 at 12:55:34PM +0200, Dmitry Adamushko wrote:
...
just a quick patch, not tested and I've not evaluated all possible
implications yet.
But someone might give it a try with his/(her -- are even more
welcomed :-) favourite sched_yield() load.
Of course, after some evaluation
OK, so to really do anything different (from a non-partitioned setup),
you would need to set sched_load_balance=0 for the root cpuset?
Yup - exactly. In fact one code fragment in my patch highlights this:
/* Special case for the 99% of systems with one, full, sched domain */
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
It seems that standard kernel list API does not have singly-linked list
manipulation.
I'm considering the following list manipulation API.
Tstsuo, please name it slist, which is
From: Paul Jackson [EMAIL PROTECTED]
Thanks to Randy Dunlap for the review that caught
some of the following.
Some bug fixes and coding style fixes:
1) only one statement per line, please.
2) don't need to guard kfree() calls with a NULL check
3) use kfifo_free, not kfree, if it came from
On 9/28/07, Frans Pop [EMAIL PROTECTED] wrote:
Current help for CONFIG_UEVENT_HELPER_PATH is:
Path to uevent helper program forked by the kernel for
every uevent.
With default value of /sbin/hotplug.
Help! I don't have /sbin/hotplug (Debian unstable, using udev).
What do I do now?
* Jarek Poplawski [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 12:55:34PM +0200, Dmitry Adamushko wrote:
...
just a quick patch, not tested and I've not evaluated all possible
implications yet.
But someone might give it a try with his/(her -- are even more
welcomed :-) favourite
On Wednesday 03 October 2007 21:38, Paul Jackson wrote:
OK, so to really do anything different (from a non-partitioned setup),
you would need to set sched_load_balance=0 for the root cpuset?
Suppose you do that to hard partition the machine, what happens to
newly created tasks like kernel
On Tue, Oct 02, 2007 at 11:37:31PM +0200, Anders Bostr?m wrote:
Hi!
My computer suffers from high load average when the system is idle,
introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Another datapoint: I observe a similar effect on both of my alphas:
top - 09:30:43 up 13
On Sat, Sep 29, 2007 at 11:48:52AM +0200, Heiko Carstens wrote:
+static inline u64 compat_merge64(u32 left, u32 right)
+{
+#if defined(__BIG_ENDIAN)
+ return ((u64)left 32) | right;
+#else /* defined (__LITTLE_ENDIAN) */
Could you change that to an #elif please and #error out if
On Wed, Oct 03, 2007 at 01:56:46PM +0200, Ingo Molnar wrote:
* Jarek Poplawski [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 12:55:34PM +0200, Dmitry Adamushko wrote:
...
just a quick patch, not tested and I've not evaluated all possible
implications yet.
But someone might
These are what I'm worried about, and things like kswapd, pdflush,
could definitely use a huge amount of CPU.
If you are interested in hard partitioning the system, you most
definitely want these things to be balanced across the non-isolated
CPUs.
But these guys are pinned anyway (or else
Hello,
I have done Streams multiplexers in Linux kernel. Created two multiplexers
and I could open these 2, close the file descriptors of each and could
link/unlink one with another properly .
But after linking, if i close the descriptor of the linked one: my signals
are unblocked
Nick wrote:
OK, so I don't exactly understand you either. To make it simple, can
you give a concrete example of a cpuset hierarchy that wouldn't
work?
It's more a matter of knowing how my third party batch scheduler
coders think. They will be off in some corner of their code with a
cpuset in
On Wednesday 03 October 2007 12:45:42 am Casey Schaufler wrote:
From: Casey Schaufler [EMAIL PROTECTED]
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and
On Wed, 03 Oct 2007 17:06:24 +0900, Shi Weihua wrote:
Fixing alternative signal stack wraparound.
If a process uses alternative signal stack by using sigaltstack()
and that stack overflow, stack wraparound occurs.
This patch checks whether the signal frame is on the alternative
stack. If
On Wed, 3 Oct 2007 09:58:44 +0200
Attila Kinali [EMAIL PROTECTED] wrote:
Hi,
This patch adds the manufacturer and card id of teltonica
pcmcia modems to serial_cs.c
Signed-off-by: Attila Kinali [EMAIL PROTECTED]
Acked-by: Alan Cox [EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Wednesday 03 October 2007 22:14, Paul Jackson wrote:
These are what I'm worried about, and things like kswapd, pdflush,
could definitely use a huge amount of CPU.
If you are interested in hard partitioning the system, you most
definitely want these things to be balanced across the
I saw top occasionally displaying % CPU usage for a process. The
first few times it was amarokapp, this last time it was kontact.
Both applications were basically idle.
The cc1 is a kernel compile (rc9 + CFS :-).
I cannot remember seeing this before, but as I also don't run top that
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
It seems that standard kernel list API does not have singly-linked list
manipulation.
I'm considering the following list
On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
Mikael Pettersson [EMAIL PROTECTED] wrote:
What I don't agree with is the logic itself:
- You only catch altstack overflow caused by the kernel pushing
a sigframe. You don't catch overflow caused by the user-space
signal handler pushing its own
pdflush
is not pinned at all and can be dynamically created and destroyed. Ditto
for kjournald, as well as many others.
Whatever is not pinned is moved out of the top cpuset, on the kind of
systems I'm most familiar with. They are put in a smaller cpuset, with
load balancing, that is sized
On Tue, 2007-10-02 at 10:00 +0800, Fengguang Wu wrote:
On Mon, Oct 01, 2007 at 11:57:34AM -0400, Chuck Ebbert wrote:
On 09/29/2007 07:04 AM, Fengguang Wu wrote:
...
(expecting real world confirmations...)
Here is a new safer version. It's more ugly though.
---
writeback: avoid
On (03/10/07 10:21), Ingo Molnar didst pronounce:
* Mel Gorman [EMAIL PROTECTED] wrote:
Nice one Ingo - got it first try. The problem commit was
dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the
code removed in this commit is put back by this latest patch.
On Oct 3 2007 14:33, Frans Pop wrote:
I saw top occasionally displaying % CPU usage for a process. The
first few times it was amarokapp, this last time it was kontact.
Both applications were basically idle.
Yes this certainly sounds like KDE. Did you try with Gnome,
or perhaps a simple
Am Mittwoch, 3. Oktober 2007 schrieb Joerg Platte:
Hi,
2.6.22.8:
open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0
2.6.23-rc9:
open(/dev/scanner,
On Wednesday 03 October 2007 22:41, Paul Jackson wrote:
pdflush
is not pinned at all and can be dynamically created and destroyed. Ditto
for kjournald, as well as many others.
Whatever is not pinned is moved out of the top cpuset, on the kind of
systems I'm most familiar with. They are
Frans Pop wrote:
I saw top occasionally displaying % CPU usage for a process. The
first few times it was amarokapp, this last time it was kontact.
Both applications were basically idle.
The cc1 is a kernel compile (rc9 + CFS :-).
I cannot remember seeing this before, but as I also don't run
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 22:04:11 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later,
On Wed, 3 Oct 2007 21:40:29 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
Mikael Pettersson [EMAIL PROTECTED] wrote:
What I don't agree with is the logic itself:
- You only catch altstack overflow caused by the kernel pushing
a sigframe. You
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is
On Wednesday 03 October 2007 22:17, Paul Jackson wrote:
Nick wrote:
OK, so I don't exactly understand you either. To make it simple, can
you give a concrete example of a cpuset hierarchy that wouldn't
work?
It's more a matter of knowing how my third party batch scheduler
coders think.
On Wed, 2007-10-03 at 22:04 +0900, Tetsuo Handa wrote:
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids
On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
hm, i just triggered the procfs crash below with -rc9 on a testbox.
Config attached. It's easy to reproduce it via 'service sshd restart'.
The crash site is:
(gdb) list *0xc017599d
0xc017599d is in seq_path
On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
How
Tetsuo Handa wrote:
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1)
Gene Heskett wrote:
On Tuesday 02 October 2007, Bill Davidsen wrote:
Gene Heskett wrote:
Indeed it went to the system halted message and just sat there. I hadn't
yet booted to rc9 as amanda was running, so I did just a few minutes ago.
After the reboot to rc9, I ran a make xconfig
On Wed, 3 Oct 2007 22:20:46 +0900, KAMEZAWA Hiroyuki wrote:
On Wed, 3 Oct 2007 21:40:29 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
Mikael Pettersson [EMAIL PROTECTED] wrote:
What I don't agree with is the logic itself:
- You only
Hello,
David Stevens wrote:
Dmitry,
Good catch; a couple comments:
Thank you for the response.
struct ipv6_pinfo *np = inet6_sk(sk);
int err;
+ int addr_type = ipv6_addr_type(addr);
+
+ if (addr_type == IPV6_ADDR_MAPPED) {
+ __be32 v4addr = addr-s6_addr32[3];
+
** RFC not for inclusion **
Although this patch is against the -rt tree, it is also applicable to
mainline after Paul's RCU preempt patches make it in.
This patch adds RCU preemption boosting to RCU readers that were
preempted (or sleep due to spin_locks in -rt).
The approach I took is similar
Correct the obvious copy and paste errors explaining some of the
find_next routines.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
arch/i386/lib/bitops.c|2 +-
arch/x86_64/lib/bitops.c |2 +-
include/asm-i386/bitops.h |5 ++---
3 files changed, 4 insertions(+), 5
* Al Viro [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
hm, i just triggered the procfs crash below with -rc9 on a testbox.
Config attached. It's easy to reproduce it via 'service sshd restart'.
The crash site is:
(gdb) list *0xc017599d
On Wed, 2007-10-03 at 22:59 +0900, Tetsuo Handa wrote:
Hello.
KaiGai Kohei wrote:
If so, you can apply RCU instead to avoid read lock
when scanning the list, like:
rcu_read_lock();
list_for_each_entry(...) {
}
rcu_read_unlock();
Can I sleep between
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later, ptr-next is assigned non-NULL address.
(3) Assigning to ptr-next is done atomically.
(4) wmb after asigning
Hello.
KaiGai Kohei wrote:
If so, you can apply RCU instead to avoid read lock
when scanning the list, like:
rcu_read_lock();
list_for_each_entry(...) {
}
rcu_read_unlock();
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock() makes
On Wednesday 03 October 2007, you wrote:
Try to capture the i/o log with the following command:
strace -o top.log top
Thanks for the suggestion.
This will show for sure whether the kernel gives out incorrect data or
top misinterprets them.
PID USER PR NI VIRT RES SHR S %CPU %MEM
On Wed, 2007-10-03 at 15:35 +0200, Kay Sievers wrote:
On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue,
On Mon, 1 Oct 2007, Linus Torvalds wrote:
So there's a final -rc out there, and right now my plan is to make this
series really short, and release 2.6.23 in a few days. So please do give
it a last good testing, and holler about any issues you find!
The r8169 nic performance regression is
Just make the __pid_nr() etc functions that expect the argument
to always be not NULL.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/include/linux/pid.h b/include/linux/pid.h
index e29a900..50b6899 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -135,21 +135,32
On Wed, 3 Oct 2007 15:46:32 +0200 (MEST)
Mikael Pettersson [EMAIL PROTECTED] wrote:
The proposed kernel signal delivery patch only handles the case
where the /sigframe/ ends up overlapping the end of the altstack.
If the sigframe remains within the altstack boundaries but the
user-space signal
On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
Charming... So we get d_path() either returning junk or we get
something that isn't NUL-terminated. Which one it is? I.e. what does
p look like and what's in s?
could be use-after-free as well, as CONFIG_PAGEALLOC was
Peter Zijlstra wrote:
Also, how do you avoid referencing dead data with your sll? I haven't
actually looked at your patches, but the simple scheme you outlined
didn't handle the iteration + concurrent removal scenario:
Regarding my singly-linked list, no entries are removed from the list. It's
There are two places that do so - the cgroups subsystem
and the autofs code.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/fs/autofs/root.c b/fs/autofs/root.c
index 592f640..5efff3c 100644
--- a/fs/autofs/root.c
+++ b/fs/autofs/root.c
@@ -214,7 +214,7 @@ static struct
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
Peter Zijlstra wrote:
Also, how do you avoid referencing dead data with your sll? I haven't
actually looked at your patches, but the simple scheme you outlined
didn't handle the
On Wed, 2007-10-03 at 23:26 +0900, Tetsuo Handa wrote:
Peter Zijlstra wrote:
Also, how do you avoid referencing dead data with your sll? I haven't
actually looked at your patches, but the simple scheme you outlined
didn't handle the iteration + concurrent removal scenario:
Regarding my
Some time ago Sukadev noticed that the vmlinux size has
grown 5Kb due to merged pid namespaces. One of the big
problems with it was fat inline functions. The other thing
was noticed by Matt - the checks for task's pid to be not
NULL take place and make the kernel grow due to inlining,
but these
Hi, I use 2.6.22.9 with CFS-v22.
When I shutdown my laptop I see a error (last message on shutdown, after
will be halt now), but I can't read because is very fast (laptop
power-off automatically).
I see something about Spindown error on ata-piix.
I try found on /var/log (messages, kern) and
On Wed, 2007-10-03 at 23:19 +0900, Tetsuo Handa wrote:
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later, ptr-next is assigned non-NULL address.
(3)
On Wed, 3 Oct 2007, Tetsuo Handa wrote:
Regarding my singly-linked list, no entries are removed from the list.
It's append only (like CD-R media). I set is_deleted flag of a entry
instead of removing the entry from the list.
Why so?
This smells like a horrible leaking of memory. How fast
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:
In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo
Handa [EMAIL PROTECTED] says:
Peter Zijlstra wrote:
Also, how do you avoid referencing dead data with your sll? I haven't
actually looked at your patches,
On Wed, 3 Oct 2007, Frans Pop wrote:
On Wednesday 03 October 2007, you wrote:
Try to capture the i/o log with the following command:
strace -o top.log top
Thanks for the suggestion.
This will show for sure whether the kernel gives out incorrect data or
top misinterprets them.
Since we now have all the tasks have non-zero pids we may
call the __pid_nr() instead of pid_nr() when the pid is
get from task with task_pid() or similar call.
Besides, there are some other places where the check for
pid to be not NULL is already done, so change them too.
Signed-off-by:
On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
On Wed, 3 Oct 2007, Frans Pop wrote:
The only change is in 2 consecutive columns: 2911 502 - 2912 500.
Is processor usage calculated from those? Can someone explain how?
The latter seems to be utime ...decreasing. No wonder if arithmetics will
401 - 500 of 716 matches
Mail list logo
