* raid5 high cpu usage during reads - oprofile results
From: Alex Izvorski @ 2006-03-25 8:38 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1143240438.8573.59.camel@starfire>
Hello,
I profiled some raid5 reads using oprofile to try to track down the
suspiciously high cpu load I see. This uses the same 8-disk SATA setup
as I had described earlier. One of runs is on a 1MB chunk raid5, the
other on a 32MB chunk raid5. As Neil suggested memcpy is a big part of
the cpu load. The rest of it apprears to be in handle_stripe and
get_active_stripe - these three account for most of the load, with the
remainder fairly evenly distributed among a dozen other routines. If
using a large chunk size, handle_stripe and get_active_stripe will
predominate (and result in some truly abnormal cpu loads). I am
attaching annotated (from opannotate) source and assembly for raid5.c
from the second (32MB chunk) run. The annotated results do not make
much sense to me, but I suspect that the exact line numbers etc may be
shifted slightly as usually happens with optimized builds. I hope this
would be useful.
Regards,
--Alex
P.S. I had originally mailed the oprofile results as attachments to the
list, but I think they didn't go through. I put them at:
http://linuxraid.pastebin.com/621363 - oprofile annotated assembly
http://linuxraid.pastebin.com/621364 - oprofile annotated source
Sorry if you get this email twice.
-----------------------------------------------------------------------
mdadm --create /dev/md0 --level=raid5 --chunk=1024 --raid-devices=8 \
--size=10485760 /dev/sd[abcdefgh]1
echo "8192" > /sys/block/md0/md/stripe_cache_size
./test_aio -f /dev/md0 -T 10 -s 60G -r 8M -n 14
throughput 205MB/s, cpu load 40%
opreport --symbols --image-path=/lib/modules/2.6.15-gentoo-r7/kernel/
samples % image name app name symbol name
91839 42.9501 vmlinux vmlinux memcpy
25946 12.1341 raid5.ko raid5 handle_stripe
17732 8.2927 raid5.ko raid5 get_active_stripe
5454 2.5507 vmlinux vmlinux blk_rq_map_sg
4850 2.2682 vmlinux vmlinux __delay
4726 2.2102 raid5.ko raid5 raid5_compute_sector
4588 2.1457 raid5.ko raid5 copy_data
4389 2.0526 raid5.ko raid5 .text
4362 2.0400 raid5.ko raid5 make_request
3688 1.7248 vmlinux vmlinux clear_page
3548 1.6593 raid5.ko raid5 raid5_end_read_request
2594 1.2131 vmlinux vmlinux blk_recount_segments
1944 0.9091 vmlinux vmlinux generic_make_request
1627 0.7609 vmlinux vmlinux dma_map_sg
1555 0.7272 vmlinux vmlinux get_user_pages
1540 0.7202 libata.ko libata ata_bmdma_status
1464 0.6847 vmlinux vmlinux __make_request
1350 0.6314 vmlinux vmlinux follow_page
1098 0.5135 vmlinux vmlinux finish_wait
...(others under 0.5%)
-----------------------------------------------------------------------
mdadm --create /dev/md0 --level=raid5 --chunk=32678 --raid-devices=8 \
--size=10485760 /dev/sd[abcdefgh]1
echo "16384" > /sys/block/md0/md/stripe_cache_size
./test_aio -f /dev/md0 -T 10 -s 60G -r 8M -n 14
throughput 207MB/s, cpu load 80%
opreport --symbols --image-path=/lib/modules/2.6.15-gentoo-r7/kernel/
samples % image name app name symbol name
112441 28.2297 raid5.ko raid5 get_active_stripe
86826 21.7988 vmlinux vmlinux memcpy
78688 19.7556 raid5.ko raid5 handle_stripe
18796 4.7190 raid5.ko raid5 .text
13301 3.3394 raid5.ko raid5 raid5_compute_sector
8339 2.0936 raid5.ko raid5 make_request
5881 1.4765 vmlinux vmlinux blk_rq_map_sg
5463 1.3716 raid5.ko raid5 raid5_end_read_request
4269 1.0718 vmlinux vmlinux __delay
4131 1.0371 raid5.ko raid5 copy_data
3531 0.8865 vmlinux vmlinux clear_page
2964 0.7441 vmlinux vmlinux blk_recount_segments
2617 0.6570 vmlinux vmlinux get_user_pages
2025 0.5084 vmlinux vmlinux dma_map_sg
...(others under 0.5%)
-----------------------------------------------------------------------
^ permalink raw reply
* [PATCH] Fixing 64-bit hvm SMP guest on 64-bit Xen
From: Nakajima, Jun @ 2006-03-25 8:37 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 252 bytes --]
This small patch allows the 64-bit Xen to run 64-bit hvm SMP guests. I'm
also working to get 32-bit hvm SMP guests running on the 64-bit Xen.
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Jun
---
Intel Open Source Technology Center
[-- Attachment #2: smp_64.patch --]
[-- Type: application/octet-stream, Size: 1627 bytes --]
diff -r 401624a17ef7 xen/arch/x86/shadow.c
--- a/xen/arch/x86/shadow.c Thu Mar 23 13:45:21 2006
+++ b/xen/arch/x86/shadow.c Sat Mar 25 00:27:01 2006
@@ -1807,6 +1807,16 @@
entry_has_changed(
guest_pt[i], snapshot_pt[i], PAGE_FLAG_MASK) )
{
+
+ unsigned long gpfn;
+
+ gpfn = entry_get_pfn(guest_pt[i]);
+ /*
+ * Looks like it's longer a page table.
+ */
+ if ( unlikely(gpfn != (gpfn & PGT_mfn_mask)) )
+ continue;
+
need_flush |= validate_entry_change(
d, &guest_pt[i], &shadow_pt[i],
shadow_type_to_level(stype));
@@ -1851,6 +1861,14 @@
{
#ifndef GUEST_PGENTRY_32
l4_pgentry_t *shadow4 = shadow;
+ unsigned long gpfn;
+
+ gpfn = l4e_get_pfn(new_root_e);
+ /*
+ * Looks like it's longer a page table.
+ */
+ if ( unlikely(gpfn != (gpfn & PGT_mfn_mask)) )
+ continue;
if ( d->arch.ops->guest_paging_levels == PAGING_L4 )
{
@@ -1894,7 +1912,7 @@
unmap_domain_page(snapshot);
unmap_domain_page(guest);
- if ( unlikely(unshadow) )
+ if ( unlikely(unshadow && stype == PGT_root_page_table) )
{
for_each_vcpu(d, v)
if(smfn == pagetable_get_pfn(v->arch.shadow_table))
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Question on build_sched_domains
From: Srivatsa Vaddagiri @ 2006-03-25 8:36 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-kernel, Ingo Molnar
In-Reply-To: <4423A391.4000301@yahoo.com.au>
On Fri, Mar 24, 2006 at 06:45:21PM +1100, Nick Piggin wrote:
> Yeah I think what's happening is that the sched groups structures
> are not shared between nodes. (It's been a while since I looked at
> this code, and it is a bit tricky to follow).
Its really odd that sched group structure aren't shared between nodes in some
case (sched_group_nodes) and are shared in other cases (sched_group_cpus,
sched_group_core, sched_group_phys).
Also is the GFP_ATOMIC allocation really required (for
sched_group_nodes) in build_sched_domains()?
--
Regards,
vatsa
^ permalink raw reply
* Re: Compile error caused by case of filename extension
From: B S Srinidhi @ 2006-03-25 8:35 UTC (permalink / raw)
To: Linux C Programming List
In-Reply-To: <200603251333.50127.samjnaa@gmail.com>
Hi,
On Sat, 2006-03-25 at 13:33 +0530, Shriramana Sharma wrote:
[..]
> $ gcc -o TESTING TESTING.C
> /tmp/ccEnQk4o.o:(.eh_frame+0x11): undefined reference to
> `__gxx_personality_v0'
> collect2: ld returned 1 exit status
>
> But if I change the input file name extension to testing.c or even TESTING.c
> (small letters) no problems were got. Why is this?
>
From the man page of gcc(1):
file.cc
file.cp
file.cxx
file.cpp
file.CPP
file.c++
file.C
C++ source code which must be preprocessed. Note that in .cxx, the
last two letters must both be literally x. Likewise, .C refers to a
literal capital C.
That means, gcc will consider a source file with name TESTING.C to be a
C++ source code. Thus trying to include / link with some special
libraries.
To compile your TESTING.C, use something like:
$ g++ -o TESTING TESTING.C
It 'll compile correctly.
Hope this helps.
Srinidhi.
--
ASCII ribbon campaign ( ) B S Srinidhi
- against HTML email X http://srinidhi.deeproot.co.in
& vCards / \ DeepRoot Linux
^ permalink raw reply
* Re: [ck] [benchmark] Interbench 2.6.16-ck/mm
From: Con Kolivas @ 2006-03-25 8:28 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: ck, André Goddard Rosa, linux list
In-Reply-To: <200603250921.32409.astralstorm@gorzow.mm.pl>
On Saturday 25 March 2006 19:21, Radoslaw Szkodzinski wrote:
> On Saturday 25 March 2006 05:01, Con Kolivas wrote yet:
> > I don't expect that staircase will be better in every single situation.
> > However it will be better more often, especially when it counts (like
> > audio or video skipping) and far more predictable. All that in 300 lines
> > less code :)
>
> I thinks the main difference is those other scheduler improvements.
> Some of them are compatible with staircase.
> Could you also try a mixed and matched 2.6.16-ck1+mm?
You're kidding, right? Check the code.
Cheers,
Con
^ permalink raw reply
* [PATCH 2.6.16-mm1 2/2] sched_domains: Allocate sched_groups dynamically
From: Srivatsa Vaddagiri @ 2006-03-25 8:28 UTC (permalink / raw)
To: Nick Piggin, Ingo Molnar, pj
Cc: hawkes, Dinakar Guniguntala, Andrew Morton, linux-kernel,
suresh.b.siddha
I hit a kernel lockup problem while making a CPUset exclusive. This was
also reported before:
http://lkml.org/lkml/2006/3/16/128 (Ref 1)
Dinakar (CCed here) said that it may be similar to the problem reported
here:
http://lkml.org/lkml/2005/8/20/40 (Ref 2)
Upon code inspection, I found that it is indeed a similar problem for
SCHED_SMT case. The problem is recreated if SCHED_SMT is enabled in the
kernel, and one tries to make a exclusive CPUset with just one thread in
it. This cause the two threads of the same CPU to be in in different
dynamic sched domains, although they share the same sched_group
structure at 'phys_domains' level. This will lead to the same kind of
corruption described in Ref 2 above.
Patch below, against 2.6.16-mm1, fixes the problem for both SCHED_SMT and
SCHED_MC cases.
I have tested the patch on a 8-way (with HT) Intel Xeon machine and
found that the lockups I was facing earlier went away with the patch.
I couldn't test this on a multi-core machine, since I don't think we
have one in our lab.
Suresh, would you mind testing the patch on a multi-core machine, in case you
have access to one?
Basically you would need to do create a exclusive CPUset with one CPU in it
(ensure that its sibling in the same core is not part of the same
CPUset). As soon as you make the CPUset exclusive, you would hit some
kind of hang. With this patch, the hang should go away.
Signed-off-by: Srivatsa Vaddagiri <vatsa@in.ibm.com>
kernel/sched.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 58 insertions(+), 9 deletions(-)
diff -puN kernel/sched.c~sd_dynschedgroups kernel/sched.c
--- linux-2.6.16-mm1/kernel/sched.c~sd_dynschedgroups 2006-03-25 11:45:05.000000000 +0530
+++ linux-2.6.16-mm1-root/kernel/sched.c 2006-03-25 13:30:01.000000000 +0530
@@ -5884,7 +5884,7 @@ static int cpu_to_cpu_group(int cpu)
#ifdef CONFIG_SCHED_MC
static DEFINE_PER_CPU(struct sched_domain, core_domains);
-static struct sched_group sched_group_core[NR_CPUS];
+static struct sched_group *sched_group_core_bycpu[NR_CPUS];
#endif
#if defined(CONFIG_SCHED_MC) && defined(CONFIG_SCHED_SMT)
@@ -5900,7 +5900,7 @@ static int cpu_to_core_group(int cpu)
#endif
static DEFINE_PER_CPU(struct sched_domain, phys_domains);
-static struct sched_group sched_group_phys[NR_CPUS];
+static struct sched_group *sched_group_phys_bycpu[NR_CPUS];
static int cpu_to_phys_group(int cpu)
{
#if defined(CONFIG_SCHED_MC)
@@ -5963,7 +5963,12 @@ next_sg:
*/
void build_sched_domains(const cpumask_t *cpu_map)
{
- int i;
+ int i, alloc_phys_failed = 0;
+ struct sched_group *sched_group_phys = NULL;
+#ifdef CONFIG_SCHED_MC
+ int alloc_core_failed = 0;
+ struct sched_group *sched_group_core = NULL;
+#endif
#ifdef CONFIG_NUMA
int alloc_failed = 0;
struct sched_group **sched_group_nodes = NULL;
@@ -6026,15 +6031,41 @@ void build_sched_domains(const cpumask_t
cpus_and(sd->span, sd->span, *cpu_map);
#endif
+ if (!sched_group_phys && !alloc_phys_failed) {
+ sched_group_phys
+ = kmalloc(sizeof(struct sched_group) * NR_CPUS,
+ GFP_KERNEL);
+ if (!sched_group_phys) {
+ printk (KERN_WARNING
+ "Can not alloc phys sched group\n");
+ alloc_phys_failed = 1;
+ }
+ sched_group_phys_bycpu[i] = sched_group_phys;
+ }
+
p = sd;
sd = &per_cpu(phys_domains, i);
group = cpu_to_phys_group(i);
*sd = SD_CPU_INIT;
sd->span = nodemask;
sd->parent = p;
- sd->groups = &sched_group_phys[group];
+ sd->groups = sched_group_phys ? &sched_group_phys[group] : NULL;
+ if (!sd->groups)
+ sd->flags = 0; /* No load balancing */
#ifdef CONFIG_SCHED_MC
+ if (!sched_group_core && !alloc_core_failed) {
+ sched_group_core
+ = kmalloc(sizeof(struct sched_group) * NR_CPUS,
+ GFP_KERNEL);
+ if (!sched_group_core) {
+ printk (KERN_WARNING
+ "Can not alloc core sched group\n");
+ alloc_core_failed = 1;
+ }
+ sched_group_core_bycpu[i] = sched_group_core;
+ }
+
p = sd;
sd = &per_cpu(core_domains, i);
group = cpu_to_core_group(i);
@@ -6042,7 +6073,9 @@ void build_sched_domains(const cpumask_t
sd->span = cpu_coregroup_map(i);
cpus_and(sd->span, sd->span, *cpu_map);
sd->parent = p;
- sd->groups = &sched_group_core[group];
+ sd->groups = sched_group_core ? &sched_group_core[group] : NULL;
+ if (!sd->groups)
+ sd->flags = 0; /* No load balancing */
#endif
#ifdef CONFIG_SCHED_SMT
@@ -6077,8 +6110,9 @@ void build_sched_domains(const cpumask_t
cpus_and(this_core_map, this_core_map, *cpu_map);
if (i != first_cpu(this_core_map))
continue;
- init_sched_build_groups(sched_group_core, this_core_map,
- &cpu_to_core_group);
+ if (sched_group_core)
+ init_sched_build_groups(sched_group_core, this_core_map,
+ &cpu_to_core_group);
}
#endif
@@ -6091,7 +6125,8 @@ void build_sched_domains(const cpumask_t
if (cpus_empty(nodemask))
continue;
- init_sched_build_groups(sched_group_phys, nodemask,
+ if (sched_group_phys)
+ init_sched_build_groups(sched_group_phys, nodemask,
&cpu_to_phys_group);
}
@@ -6249,9 +6284,9 @@ static void arch_init_sched_domains(cons
static void arch_destroy_sched_domains(const cpumask_t *cpu_map)
{
+ int cpu;
#ifdef CONFIG_NUMA
int i;
- int cpu;
for_each_cpu_mask(cpu, *cpu_map) {
struct sched_group *sched_group_allnodes
@@ -6289,6 +6324,20 @@ next_sg:
sched_group_nodes_bycpu[cpu] = NULL;
}
#endif
+ for_each_cpu_mask(cpu, *cpu_map) {
+ if (sched_group_phys_bycpu[cpu]) {
+ kfree(sched_group_phys_bycpu[cpu]);
+ sched_group_phys_bycpu[cpu] = NULL;
+ }
+ }
+#ifdef CONFIG_SCHED_MC
+ for_each_cpu_mask(cpu, *cpu_map) {
+ if (sched_group_core_bycpu[cpu]) {
+ kfree(sched_group_core_bycpu[cpu]);
+ sched_group_core_bycpu[cpu] = NULL;
+ }
+ }
+#endif
}
/*
_
_
--
Regards,
vatsa
^ permalink raw reply
* [PATCH 2.6.16-mm1 1/2] sched_domain: handle kmalloc failure
From: Srivatsa Vaddagiri @ 2006-03-25 8:27 UTC (permalink / raw)
To: Nick Piggin, Ingo Molnar
Cc: suresh.b.siddha, pj, hawkes, linux-kernel, Dinakar Guniguntala,
Andrew Morton
I think there is a bug in build_sched_domains() when kmalloc fails to
allocate memory for 'sched_group_allnodes'.
Consider the case where build_sched_domains() is being invoked because a
CPUset is being made exclusive. Further lets say user changed cpu_exclusive
property of some CPUset as follow:
echo 1 > cpu_exclusive # (Step a)
echo 0 > cpu_exclusive # (Step b)
echo 1 > cpu_exclusive # (Step c)
Lets say that all memory allocations succeeded during the 1st attempt to
make CPUset exclusive (Step a). Step a would result in the sched domain
heirarchy being initialized for all CPUs in the CPUSet under
consideration. Step b would cause those memory allocations to be freed
up.
Now during Step c, lets say that kmalloc failed to allocate for
'sched_group_allnodes'. When that happens, the code just breaks out of
the 'for' loop. I think that is wrong, as it would cause the previous
assignments (made during Step a) to be retained. This could cause, among
other things, sd->groups to be invalid (for allnodes_domains)?
Patch below (against 2.6.16-mm1) fixes it. I have done some minimal test
of it.
Signed-off-by: Srivatsa Vaddagiri <vatsa@in.ibm.com>
kernel/sched.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff -puN kernel/sched.c~sd_handle_error kernel/sched.c
--- linux-2.6.16-mm1/kernel/sched.c~sd_handle_error 2006-03-25 11:39:07.000000000 +0530
+++ linux-2.6.16-mm1-root/kernel/sched.c 2006-03-25 11:39:59.000000000 +0530
@@ -5965,6 +5965,7 @@ void build_sched_domains(const cpumask_t
{
int i;
#ifdef CONFIG_NUMA
+ int alloc_failed = 0;
struct sched_group **sched_group_nodes = NULL;
struct sched_group *sched_group_allnodes = NULL;
@@ -5993,7 +5994,7 @@ void build_sched_domains(const cpumask_t
#ifdef CONFIG_NUMA
if (cpus_weight(*cpu_map)
> SD_NODES_PER_DOMAIN*cpus_weight(nodemask)) {
- if (!sched_group_allnodes) {
+ if (!sched_group_allnodes && !alloc_failed) {
sched_group_allnodes
= kmalloc(sizeof(struct sched_group)
* MAX_NUMNODES,
@@ -6001,7 +6002,7 @@ void build_sched_domains(const cpumask_t
if (!sched_group_allnodes) {
printk(KERN_WARNING
"Can not alloc allnodes sched group\n");
- break;
+ alloc_failed = 1;
}
sched_group_allnodes_bycpu[i]
= sched_group_allnodes;
@@ -6010,7 +6011,10 @@ void build_sched_domains(const cpumask_t
*sd = SD_ALLNODES_INIT;
sd->span = *cpu_map;
group = cpu_to_allnodes_group(i);
- sd->groups = &sched_group_allnodes[group];
+ sd->groups = sched_group_allnodes ?
+ &sched_group_allnodes[group] : NULL;
+ if (!sd->groups)
+ sd->flags = 0; /* No load balancing */
p = sd;
} else
p = NULL;
_
--
Regards,
vatsa
^ permalink raw reply
* Re: [ck] [benchmark] Interbench 2.6.16-ck/mm
From: Radoslaw Szkodzinski @ 2006-03-25 8:21 UTC (permalink / raw)
To: ck; +Cc: Con Kolivas, André Goddard Rosa, linux list
In-Reply-To: <200603251501.32592.kernel@kolivas.org>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
On Saturday 25 March 2006 05:01, Con Kolivas wrote yet:
>
> I don't expect that staircase will be better in every single situation.
> However it will be better more often, especially when it counts (like audio
> or video skipping) and far more predictable. All that in 300 lines less
> code :)
>
I thinks the main difference is those other scheduler improvements.
Some of them are compatible with staircase.
Could you also try a mixed and matched 2.6.16-ck1+mm?
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Eric Wong @ 2006-03-25 8:25 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060324182504.GI31387@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>
> Since it seems nobody looked at the GCC import run (which means to use
> the svnimport), I ran it again, under strace control:
If you don't care for automated branch handling, how about trying git-svn?
under the contrib/ directory in git.git
git-svn init svn://gcc.gnu.org/svn/gcc
git-svn fetch
> > GCC
> > ~~~
> > $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
>
> > Committed change 3936:/ 1993-03-31 05:44:03)
> > Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e
> > Writing to refs/heads/origin
> > DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e
> > ... 3937 trunk/gcc/final.c ...
> > Can't fork at /home/jbglaw/bin/git-svnimport line 379.
>
> ... 4279 trunk/gcc/config/i386/xm-sco.h ...
>
> This time it broke at a different revision, so I guess it's not a SVN
> or git / git-svnimport problem, but rather a problem of my Perl
> installation or the kernel itself?
I've known of SVN library bindings leaking memory in the past, but I
thought it's been solved. Afaik, any memory allocated by the Perl
interpreter is never released back to the kernel, either. (At least
that seems to be the case with my setup (Debian unstable, Perl 5.8.8,
2.6 kernel, x86 machine).
> What are possible reasons for clone() to fail with -ENOMEN? I have to
> admit that the box _is_ loaded a bit all the time:
>
> jbglaw@bixie:~/vax/git-conversion$ uptime
> 19:23:58 up 136 days, 7:46, 20 users, load average: 4.45, 4.25, 3.05
> jbglaw@bixie:~/vax/git-conversion$ free
> total used free shared buffers cached
> Mem: 507308 501760 5548 0 2184 16900
> -/+ buffers/cache: 482676 24632
> Swap: 2441872 1295512 1146360
Some importers (my own git-svn included) aren't amazingly efficient when
handling lots of history which gcc has. It looks like (from what I
understand of the SVN api used in git-svnimport) is that the entire log
for the 100k+ revisions in the tree is slurped down into memory before
any processing is done.
git-svn does this too, but by parsing the output of the svn binary
instead of using the library, so at least it won't have issues with the
svn bindings and libraries to worry about.
My git-svn process running on the SVN tree just finished parsing the svn
log output, and it's maxed out at 74M RSS (on a 32-bit x86). It'll
probably take a while to import it all (which I won't do), but I could
have just as easily done the following to reduce memory usage by ~half:
git-svn fetch -r0:50000 # import the first 50000k
git-svn fetch # now import the remaining
Afaik, there's no way to do something like the above with git-svnimport
for memory-starved setups.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] suspend.c: make sure stdin, stdout and stderr are open
From: Stefan Rompf @ 2006-03-25 8:20 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm
In-Reply-To: <200603242355.48702.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
Am Freitag 24 März 2006 23:55 schrieb Rafael J. Wysocki:
> I've redone your patch a bit, could you please test it?
Works nicely, thanks, but why did you move the loop downwards, so that it is
executed after reading config and calling into libcrypto?
As you asked for the distribution I use, it is SuSE 9.3 on i386, 2.6.16 with
some patches (uswsusp, RFC2863-operstate, avoid "udev vc" bloat).
Stefan
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: 2.6.16 hugetlbfs problem - DEBUG_PAGEALLOC
From: Andrew Morton @ 2006-03-25 8:15 UTC (permalink / raw)
To: Chen, Kenneth W; +Cc: mrustad, linux-kernel
In-Reply-To: <200603250728.k2P7Sog25321@unix-os.sc.intel.com>
"Chen, Kenneth W" <kenneth.w.chen@intel.com> wrote:
>
> Andrew Morton wrote on Friday, March 24, 2006 6:54 PM
> > "Chen, Kenneth W" <kenneth.w.chen@intel.com> wrote:
> > >
> > > Mark Rustad wrote on Friday, March 24, 2006 9:52 AM
> > > > I have narrowed this down to DEBUG_PAGEALLOC. If that option is
> > > > enabled, attempts to reference areas mmap-ed from hugetlbfs files
> > > > fault forever. You can see that I had that set in the failing config
> > > > I reported below.
> > >
> > > Yeah, it turns out that the debug option is not compatible with hugetlb
> > > page support. That debug option turns off PSE. Once it is turned off in
> > > CR4, cpu will ignore pse bit in the pmd and causing infinite page-not-
> > > present fault :-(
> >
> > I wonder if any of the other architectures which implement both these
> > features might have problems too.
>
>
> Only 32-bit x86 arch implements both. We get away by not having DEBUG_PAGEALLOC
> feature on any other arch.
OK, thanks.
> ...
> I was going to verify that on my ia32 box, but apparently, turning on
> 64G highmem gives me machine reset at boot. (is it a known regression?)
Works OK here.
quad:/home/akpm> cat /proc/meminfo
MemTotal: 7251348 kB
MemFree: 7180680 kB
Buffers: 18868 kB
Cached: 20980 kB
SwapCached: 0 kB
Active: 32100 kB
Inactive: 14440 kB
HighTotal: 6422528 kB
HighFree: 6390924 kB
LowTotal: 828820 kB
LowFree: 789756 kB
SwapTotal: 4000040 kB
SwapFree: 4000040 kB
Dirty: 128 kB
Writeback: 0 kB
Mapped: 10112 kB
Slab: 11352 kB
CommitLimit: 7625712 kB
Committed_AS: 15292 kB
PageTables: 520 kB
VmallocTotal: 118776 kB
VmallocUsed: 2180 kB
VmallocChunk: 116356 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
^ permalink raw reply
* Compile error caused by case of filename extension
From: Shriramana Sharma @ 2006-03-25 8:03 UTC (permalink / raw)
To: Linux C Programming List
When the contents of TESTING.C are:
#include "stdio.h"
void main(void)
{
printf("\n%d\n", ( -0.25 < 0) ? 2 : 4);
}
Upon trying to compile:
$ gcc -o TESTING TESTING.C
TESTING.C:3: error: ‘::main’ must return ‘int’
Then I changed the file to:
#include "stdio.h"
int main(void)
{
printf("\n%d\n", ( -0.25 < 0) ? 2 : 4);
return 1;
}
Then I got:
$ gcc -o TESTING TESTING.C
/tmp/ccEnQk4o.o:(.eh_frame+0x11): undefined reference to
`__gxx_personality_v0'
collect2: ld returned 1 exit status
But if I change the input file name extension to testing.c or even TESTING.c
(small letters) no problems were got. Why is this?
--
Tux #395953 resides at http://samvit.org
playing with KDE 3.51 on SUSE Linux 10.0
$ date [] CCE +2006-03-25 W12-6 UTC+0530
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Fix branch ancestry calculation
From: Keith Packard @ 2006-03-25 7:54 UTC (permalink / raw)
To: Chris Shoemaker
Cc: keithp, Linus Torvalds, David Mansfield, David Mansfield,
Git Mailing List
In-Reply-To: <20060325014532.GB32522@pe.Belkin>
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On Fri, 2006-03-24 at 20:45 -0500, Chris Shoemaker wrote:
> If that last sentence was a typo then you already know this, but
> otherwise you may be disappointed to learn that it's not _always_
> possible to discern the correct ancestry tree.
Sure, it's possible to generate trees which can't be figured out. So
far, I haven't found any which can't be pieced back together, except in
cases where the tree was accidentally damaged (child branches created on
two separate parent branches)
> If you end up comparing the ancestry tree discovered by your tool and
> the tree output by a patched cvsps, I would be very interested in the
> results.
So far, I've found several concrete trees where cvsps (in any form)
assigns branch points many versions too early compared to the 'true'
history. My tool is getting better answers, but still can't compute the
tree for the X.org X server tree yet. That one has a wide variety of
damage, including the direct copying of ,v files between repositories
which had divered, and the accidental branching of files from different
parent branches. I keep poking at it...
> -chris
>
> (*) You can distinguish between A->B->head and B->A->head simply by
> date.
I'm doing a lot more date-based identification than I'm really
comfortable with; the bad thing here is that branch points can occur
long before any commits to that branch, when doing date-based
operations, you have a range of possible matching branch points and it's
hard to disambiguate.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* IDE sysfs corrupted (second IDE channel parent lost) after resume from STR
From: Andrey Borzenkov @ 2006-03-25 7:51 UTC (permalink / raw)
To: linux-ide; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This can be reproduced both in 2.6.15.6 and 2.6.16. Toshiba with Ali chipset,
driver compiled in as module. After system resumed from suspend-to-ram,
second channel of IDE controller loses its parent.
Before suspend:
total 0
lrwxrwxrwx 1 root root 0 Mar 25 10:38 0.0
- -> ../../../devices/pci0000:00/0000:00:04.0/ide0/0.0/
lrwxrwxrwx 1 root root 0 Mar 25 10:38 1.0
- -> ../../../devices/pci0000:00/0000:00:04.0/ide1/1.0/
After resume:
total 0
lrwxrwxrwx 1 root root 0 Mar 25 10:38 0.0
- -> ../../../devices/pci0000:00/0000:00:04.0/ide0/0.0/
lrwxrwxrwx 1 root root 0 Mar 25 10:41 1.0 -> ../../../devices/ide1/1.0/
I include dmesg output from 2.6.16; it can be seen that at least for second
channel probe_hwif() is called but apparently at this time it does not have
proper ->pci_dev set; I could find call chain that would have lead to this.
Please let me know if more information (like config or lspci) are needed.
Kernel does not contain binary drivers :)
Regards
- -andreyLinux version 2.6.16-2avb (bor@cooker.home.net) (gcc version 4.0.3
(4.0.3-1mdk for Mandriva Linux release 2006.1)) #4 Tue Mar 21 22:26:51 MSK
2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 00000000000eee00 (reserved)
BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ef60000 (usable)
BIOS-e820: 000000001ef60000 - 000000001ef70000 (ACPI data)
BIOS-e820: 000000001ef70000 - 0000000020000000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
495MB LOWMEM available.
On node 0 totalpages: 126816
DMA zone: 4096 pages, LIFO batch:0
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 122720 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:0
DMI 2.3 present.
ACPI: RSDP (v000 TOSHIB ) @ 0x000f0090
ACPI: RSDT (v001 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x1ef60000
ACPI: FADT (v002 TOSHIB 750 0x00970814 TASM 0x04010000) @ 0x1ef60054
ACPI: DSDT (v001 TOSHIB 4000 0x20020417 MSFT 0x0100000a) @ 0x00000000
ACPI: PM-Timer IO Port: 0xee08
Allocating PCI resources starting at 30000000 (gap: 20000000:dff80000)
Built 1 zonelists
Kernel command line: root=/dev/hda2 pinit hdc=ide-cd resume=/dev/hda1
splash=silent elevator=cfq vga=791
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (013e2000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 747.770 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 498992k/507264k available (1885k kernel code, 7628k reserved, 565k
data, 196k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1498.62 BogoMIPS
(lpj=2997249)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0387f9ff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: After vendor identify, caps: 0387f9ff 00000000 00000000 00000000 00000000
00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 0a
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0a00)
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 324k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfe5ae, last bus=5
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region ee00-ee3f claimed by ali7101 ACPI
PCI quirk: region ef00-ef1f claimed by ali7101 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: Power Resource [PFAN] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: f7f00000-fdffffff
PREFETCH window: 3c000000-3c0fffff
PCI: Bus 2, cardbus bridge: 0000:00:10.0
IO window: 00001000-000010ff
IO window: 00001400-000014ff
PREFETCH window: 30000000-31ffffff
MEM window: 32000000-33ffffff
PCI: Bus 6, cardbus bridge: 0000:00:11.0
IO window: 00001800-000018ff
IO window: 00001c00-00001cff
PREFETCH window: 34000000-35ffffff
MEM window: 36000000-37ffffff
PCI: Bus 10, cardbus bridge: 0000:00:11.1
IO window: 00002000-000020ff
IO window: 00002400-000024ff
PREFETCH window: 38000000-39ffffff
MEM window: 3a000000-3bffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Enabling device 0000:00:10.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) ->
IRQ 11
PCI: Enabling device 0000:00:11.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) ->
IRQ 11
PCI: Enabling device 0000:00:11.1 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) ->
IRQ 11
audit: initializing netlink socket (disabled)
audit(1143268855.064:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Activating ISA DMA hang workarounds.
vesafb: framebuffer at 0xfc000000, mapped to 0xdf880000, using 3072k, total
16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: protected mode interface info at c000:775e
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Real Time Clock Driver v1.12ac
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
input: AT Translated Set 2 keyboard as /class/input/input0
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 6, 262144 bytes)
TCP bind hash table entries: 16384 (order: 6, 327680 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
Using IPI Shortcut mode
swsusp: Resume From Partition /dev/hda1
PM: Checking swsusp image.
swsusp: Error -6 check for resume file
PM: Resume from disk failed.
ACPI wakeup devices:
COM USB1 ASND VIY0 VIY1 LAN MPC0 MPC1 NOV0 LID
ACPI: (supports S0 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot 0000:00:04.0
ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI
ALI15X3: chipset revision 195
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xeff0-0xeff7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xeff8-0xefff, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: IC25N020ATDA04-0, ATA DISK drive
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 39070080 sectors (20003 MB) w/1806KiB Cache, CHS=38760/16/63, UDMA(33)
hda: cache flushes not supported
hda: hda1 hda2
ReiserFS: hda2: found reiserfs format "3.6" with standard journal
ReiserFS: hda2: using ordered data mode
ReiserFS: hda2: journal params: device hda2, size 8192, journal first block
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda2: checking transaction log (hda2)
ReiserFS: hda2: Using r5 hash to sort names
Freeing unused kernel memory: 196k freed
Write protecting the kernel read-only data: 266k
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) ->
IRQ 11
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) ->
IRQ 11
Yenta: CardBus bridge found at 0000:00:10.0 [12a3:ab01]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:10.0, mfunc 0x01000002, devctl 0x60
Yenta: ISA IRQ mask 0x0000, PCI irq 11
Socket status: 30000059
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) ->
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.0 [1179:0001]
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xcbfff 0xe0000-0xfffff
cs: memory probe 0x60000000-0x60ffffff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
pcmcia: registering new device pcmcia0.0
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) ->
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.1 [1179:0001]
wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere Systems,
http://www.agere.com
*** Modified for kernel 2.6 by Andrey Borzenkov <arvidjaar@mail.ru> $Revision:
19 $
*** Station Mode (STA) Support: YES
*** Access Point Mode (AP) Support: YES
eth0: PRI 31 variant 2 version 9.48
eth0: NIC 5 variant 2 version 1.02
eth0: Wireless, io_addr 0x100, irq 11, mac_address 00:02:2D:26:95:6C
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
ts: Compaq touchscreen protocol output
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected ALi M1644 chipset
agpgart: AGP aperture is 64M @ 0xf0000000
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Battery Slot [BAT2] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (49 C)
toshiba_acpi: Toshiba Laptop ACPI Extras version 0.18
toshiba_acpi: HCI method: \_SB_.VALD.GHCI
ACPI: Video Device [VGA] (multi-head: yes rom: yes post: no)
Adding 500432k swap on /dev/hda1. Priority:-1 extents:1 across:500432k
loop: loaded (max 8 devices)
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKH] -> GSI 11 (level, low) ->
IRQ 11
NET: Registered protocol family 17
pcmcia: Detected deprecated PCMCIA ioctl usage.
pcmcia: This interface will soon be removed from the kernel; please expect
breakage unless you upgrade to new tools.
pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html
for details.
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) ->
IRQ 11
e100: eth0: e100_probe: addr 0xf7efd000, irq 11, MAC addr 00:00:39:D7:14:A1
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
i2c_adapter i2c-0: Error: command never completed
i2c_adapter i2c-0: Adapter hung, retrying after reset
i2c_adapter i2c-0: Error: command never completed
i2c_adapter i2c-0: Adapter hung, retrying after reset
i2c_adapter i2c-0: Error: command never completed
i2c_adapter i2c-0: Adapter hung, retrying after reset
========== suspend start ======================
ACPI: PCI interrupt for device 0000:00:06.0 disabled
ACPI: PCI interrupt for device 0000:00:0a.0 disabled
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) ->
IRQ 11
e100: eth0: e100_probe: addr 0xf7efd000, irq 11, MAC addr 00:00:39:D7:14:A1
pccard: card ejected from slot 0
PM: Preparing system for mem sleep
Stopping tasks:
==================================================================================|
pnp: Device 00:09 disabled.
ACPI: PCI interrupt for device 0000:00:11.1 disabled
ACPI: PCI interrupt for device 0000:00:11.0 disabled
ACPI: PCI interrupt for device 0000:00:10.0 disabled
ACPI: PCI interrupt for device 0000:00:0a.0 disabled
ACPI: PCI interrupt for device 0000:00:02.0 disabled
PM: Entering mem sleep
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
Debug: sleeping function called from invalid context
at /home/bor/src/linux-git/mm/slab.c:2729
in_atomic():0, irqs_disabled():1
[<c0104213>] show_trace+0x13/0x20
[<c010423e>] dump_stack+0x1e/0x20
[<c0116032>] __might_sleep+0xa2/0xc0
[<c015c533>] kmem_cache_alloc+0x53/0x70
[<c01f2a53>] acpi_os_acquire_object+0x11/0x41
[<c020843f>] acpi_ut_allocate_object_desc_dbg+0xf/0x44
[<c02084cb>] acpi_ut_create_internal_object_dbg+0x16/0x6a
[<c0204807>] acpi_rs_set_srs_method_data+0x40/0xb9
[<c0203f05>] acpi_set_current_resources+0x23/0x2e
[<c020bd7b>] acpi_pci_link_set+0xff/0x17b
[<c020be2e>] irqrouter_resume+0x37/0x56
[<c0236b8a>] __sysdev_resume+0x1a/0x90
[<c0236c47>] sysdev_resume+0x47/0x70
[<c023c648>] device_power_up+0x8/0x10
[<c0138b7a>] enter_state+0x1ba/0x220
[<c0138c77>] state_store+0x97/0xb0
[<c01a188e>] subsys_attr_store+0x2e/0x30
[<c01a1e63>] sysfs_write_file+0xb3/0x100
[<c015fe57>] vfs_write+0xa7/0x190
[<c0160867>] sys_write+0x47/0x70
[<c0102f07>] sysenter_past_esp+0x54/0x75
PM: Finishing wakeup.
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) ->
IRQ 11
ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) ->
IRQ 11
pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: Wireless, io_addr 0x100, irq 11, mac_address 00:02:2D:26:95:6C
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) ->
IRQ 11
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) ->
IRQ 11
pnp: Failed to activate device 00:05.
pnp: Failed to activate device 00:06.
pnp: Device 00:09 activated.
usb usb1: root hub lost power or was reset
Restarting tasks... done
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
eth1: PRI 31 variant 2 version 9.48
eth1: NIC 5 variant 2 version 1.02
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
NET: Registered protocol family 23
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKH] -> GSI 11 (level, low) ->
IRQ 11
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEJPZvR6LMutpd94wRAoLqAJ0UxvE3WGtDsreVeql2xhAmpmKHbgCgxiDh
kspfyJ6bWdSfXrfsLuyGAC0=
=vbuO
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: eCryptfs Design Document
From: Miklos Szeredi @ 2006-03-25 7:38 UTC (permalink / raw)
To: akpm
Cc: mhalcrow, phillip, linux-kernel, linux-fsdevel, viro, mike,
mcthomps, yoder1, toml, emilyr, daw
In-Reply-To: <20060324163358.557ac5f7.akpm@osdl.org>
> > > One dutifully wonders whether all this functionality could be
> > > provided via FUSE...
> >
> > My main concern with FUSE has to do with shared memory mappings.
>
> OK. But I'm sure Miklos would appreciate help with that ;)
You bet.
> > My next concern is with regard to performance impact of constant
> > context switching during page reads and writes.
>
> Maybe. One could estimate the cost of that by benchmarking an existing
> (efficient) FUSE fs and then add fiddle factors. If the number of copies
> is the same for in-kernel versus FUSE then one would expect the performance
> to be similar. Especially if the encrypt/decryption cost perponderates.
The main overhead of FUSE is not in copies, but in context switching.
For I/O that can be mitigated by doing it in big chunks, otherwise the
only solution is adding more processors.
Miklos
^ permalink raw reply
* Re: Use a *real* built-in diff generator
From: Junio C Hamano @ 2006-03-25 7:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vk6ajxbe5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> This uses a simplified libxdiff setup to generate unified diffs _without_
>> doing fork/execve of GNU "diff".
>
> Good stuff.
The reason I like this is because I was thinking about doing
in-core diffs for different purpose when I was driving to work
this morning [*1*] --- to make pickaxe a more useful building
block.
Currently, pickaxe tries to do an exact match to find the case
where a given substring S appears in the version C of the file
but not in the its parent C^n (1 <= n), and then it tells the
diffcore to emit the differences. The user (probably only me on
this list?) is expected to look at the change, make an
intelligent decision to feed a matching substring S' found in
C^n and restart from that commit.
To be a useful "content movement tracker", the process of
finding matching 'old shape' in the previous version and
re-feeding it to pickaxe should be automated if possible, and
in-core diff machinery would be one component to help that.
For example, if I wanted to find when I stole 'ls-files -t'
feature from Cogito, I would first run less ls-files.c; I see
these and am reasonably sure these relate to what I am looking
for:
...
static const char *tag_cached = "";
static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified = "";
...
So I run:
$ git whatchanged -S'static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified' -p master -- ls-files.c
which finds:
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Sep 19 15:11:15 2005 -0700
Show modified files in git-ls-files
...
@@ -28,6 +29,7 @@ static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
+static const char *tag_modified = "";
but that is not what I am interested in; the matching "old
shape" is the version before the tag_modified was added (and it
already had other tag_xxx in there). So with the current
pickaxe, I manually re-run whatchanged starting from the found
commit with modified string like this:
$ git whatchanged -S'static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";' -p $that_commit -- ls-files.c
in order to further drill down.
A truly useful pickaxe should take two line numbers and a
filename (to name the range of lines I am interested in) from
the starting version, notice when that range changes shape, and
after showing the found commit, replace the range with the one
matching from the older commit and continue.
[Footnote]
*1* When you are bogged down in a boring day-job, your brain
tends to try to compensate by spending as much your waking time
as possible on thinking about more interesting and more useful
stuff -- like git ;-).
^ permalink raw reply
* [ALSA - driver 0001964]: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
From: bugtrack @ 2006-03-25 7:38 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1964>
======================================================================
Reported By: sharpen047
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1964
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 03-25-2006 08:24 CET
Last Modified: 03-25-2006 08:38 CET
======================================================================
Summary: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
Description:
alsa mixer is up tried for about 2 months now to fix this... i dont know
what to do tell me what to post and youll get it
thanks!
======================================================================
----------------------------------------------------------------------
sharpen047 - 03-25-06 08:38
----------------------------------------------------------------------
localhost ~ # modprobe snd-hda-intel
WARNING: Error inserting snd_timer
(/lib/modules/2.6.15-gentoo-r1/kernel/sound/acore/snd-timer.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
WARNING: Error inserting snd_pcm
(/lib/modules/2.6.15-gentoo-r1/kernel/sound/acore/snd-pcm.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd_hda_intel
(/lib/modules/2.6.15-gentoo-r1/alsa-driver/pci/snd-hda-intel.ko): Unknown
symbol in module, or unknown parameter (see dmesg)
Issue History
Date Modified Username Field Change
======================================================================
03-25-06 08:24 sharpen047 New Issue
03-25-06 08:38 sharpen047 Note Added: 0008943
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* RE: 2.6.16 hugetlbfs problem - DEBUG_PAGEALLOC
From: Chen, Kenneth W @ 2006-03-25 7:29 UTC (permalink / raw)
To: 'Andrew Morton'; +Cc: mrustad, linux-kernel
In-Reply-To: <20060324185331.56837b0a.akpm@osdl.org>
Andrew Morton wrote on Friday, March 24, 2006 6:54 PM
> "Chen, Kenneth W" <kenneth.w.chen@intel.com> wrote:
> >
> > Mark Rustad wrote on Friday, March 24, 2006 9:52 AM
> > > I have narrowed this down to DEBUG_PAGEALLOC. If that option is
> > > enabled, attempts to reference areas mmap-ed from hugetlbfs files
> > > fault forever. You can see that I had that set in the failing config
> > > I reported below.
> >
> > Yeah, it turns out that the debug option is not compatible with hugetlb
> > page support. That debug option turns off PSE. Once it is turned off in
> > CR4, cpu will ignore pse bit in the pmd and causing infinite page-not-
> > present fault :-(
>
> I wonder if any of the other architectures which implement both these
> features might have problems too.
Only 32-bit x86 arch implements both. We get away by not having DEBUG_PAGEALLOC
feature on any other arch.
I read the ia32 processor manual, it says the pse flag in CR4 controls
4K/4M mapping in addition to pse bit in page directory entry. But in
PAE mode, cr4.pse is ignored and pse bit in pmd controls 4K/2M mapping.
I was going to verify that on my ia32 box, but apparently, turning on
64G highmem gives me machine reset at boot. (is it a known regression?)
X86-64 surly ignores cr4.pse for 4K/2M mapping. It is solely controlled
by pse bit in pmd.
- Ken
^ permalink raw reply
* [ALSA - driver 0001964]: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
From: bugtrack @ 2006-03-25 7:24 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1964>
======================================================================
Reported By: sharpen047
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1964
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 03-25-2006 08:24 CET
Last Modified: 03-25-2006 08:24 CET
======================================================================
Summary: CMedia 9880 ECS 915p-a 1.2a NO MIC/LINE IN
Description:
alsa mixer is up tried for about 2 months now to fix this... i dont know
what to do tell me what to post and youll get it
thanks!
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
03-25-06 08:24 sharpen047 New Issue
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [PATCH] Fixed build error with debug=y
From: Masaki Kanno @ 2006-03-25 7:22 UTC (permalink / raw)
To: xen-devel, xen-ia64-devel
[-- Attachment #1: Type: text/plain, Size: 202 bytes --]
Hi,
This patch fixed build error with debug=y in the xen/ia64.
The MAX_ORDER definition has moved into the header file.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Best regards,
Kan
[-- Attachment #2: MAX_ORDER.patch --]
[-- Type: application/octet-stream, Size: 992 bytes --]
diff -r 2e81aba147eb xen/common/page_alloc.c
--- a/xen/common/page_alloc.c Fri Mar 24 11:36:22 2006 -0700
+++ b/xen/common/page_alloc.c Sat Mar 25 16:15:56 2006 +0900
@@ -219,8 +219,6 @@ unsigned long alloc_boot_pages(unsigned
#define pfn_dom_zone_type(_pfn) \
(((_pfn) <= MAX_DMADOM_PFN) ? MEMZONE_DMADOM : MEMZONE_DOM)
-/* Up to 2^20 pages can be allocated at once. */
-#define MAX_ORDER 20
static struct list_head heap[NR_ZONES][MAX_ORDER+1];
static unsigned long avail[NR_ZONES];
diff -r 2e81aba147eb xen/include/xen/mm.h
--- a/xen/include/xen/mm.h Fri Mar 24 11:36:22 2006 -0700
+++ b/xen/include/xen/mm.h Sat Mar 25 16:15:56 2006 +0900
@@ -68,6 +68,9 @@ unsigned long avail_domheap_pages(void);
#define ALLOC_DOM_DMA 1
+/* Up to 2^20 pages can be allocated at once. */
+#define MAX_ORDER 20
+
/* Automatic page scrubbing for dead domains. */
extern struct list_head page_scrub_list;
#define page_scrub_schedule_work() \
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Effective difference between git-rebase and git-resolve
From: Junio C Hamano @ 2006-03-25 7:15 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20060325063225.GA13791@buici.com>
Marc Singer <elf@buici.com> writes:
[I'm shuffling this part to the top]
> Moreover, it isn't clear to me if git-rebase is better than git-merge.
Merge preserves commit ancestry, so if you are hoping it to
clean up your history, that is not the tool to do it. Both
rebase and cherry-pick are to help you create a cleaner,
alternate history. So none is better than the other. They
serve different purposes.
> On Fri, Mar 24, 2006 at 10:08:09PM -0800, Junio C Hamano wrote:
>> > Junio, is there some magic to restart a rebase after you've fixed up the
>> > conflicts?
>>
>> The modern rebase is essentially git-format-patch piped to
>> git-am (with -3 flag to allow falling back to three-way merge),
>> and all the familiar "the patch did not apply -- what now?"
>> techniques can be employed.
>...
> By modern do you mean newer than 1.2.4? I comprehend what you're
> layin' down here, but I don't know if I need to do something
> different.
By modern, I meant v0.99.9-g7f59dbb.
diff-tree 7f59dbb... (from f9039f3...)
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Nov 14 00:41:53 2005 -0800
Rewrite rebase to use git-format-patch piped to git-am.
The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.
Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.
Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion. You fetch
from upstream head U and find that B has been picked up. You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.
Now what?
It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand. Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.
Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.
This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge. The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.
The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:
- A series of patches in e-mail form is created that records
what A-C-D-E do, and is fed to git-am. This is stored in
.dotest/ directory, just like the case you tried to apply
them from your mailbox. Your branch is rewound to the tip of
upstream U, and the original head is kept in .git/ORIG_HEAD,
so you could "git reset --hard ORIG_HEAD" in case the end
result is really messy.
- Patch A applies cleanly. This could either be a clean patch
application on top of rewound head (i.e. same as upstream
head), or git-am might have internally fell back on 3-way
(i.e. it would have done the same thing as git-cherry-pick).
In either case, a rebased commit A is made on top of U.
- Patch C does not apply. git-am stops here, with conflicts to
be resolved in the working tree. Yet-to-be-applied D and E
are still kept in .dotest/ directory at this point. What the
user does is exactly the same as fixing up unapplicable patch
when running git-am:
- Resolve conflict just like any merge conflicts.
- "git am --resolved --3way" to continue applying the patches.
- This applies the fixed-up patch so by definition it had
better apply. "git am" knows the patch after the fixed-up
one is D and then E; it applies them, and you will get the
changes from A-C-D-E commits on top of U, in this order.
I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Modify the sock Structure!!
From: Benjamin @ 2006-03-25 7:11 UTC (permalink / raw)
To: linux-kernel
Hello! I try to modify the sock Structure in sock.h in order to record
some data!
I just add a unsigned short in the end of the structure. such as:
struct sock {
/* Socket demultiplex comparisons on incoming packets. */
__u32 daddr; /* Foreign IPv4 addr */
__u32 rcv_saddr; /* Bound local IPv4 addr */
...................................................................
....................................................................
void (*destruct)(struct sock *sk);
unsigned short data; /*I put the unsigned short
here*/
};
I re-complied the kernel. The kernel and network functions work
normally so far.
However, I am a new guy for the kernel programming. I just wonder this
modification is
safe or not. Is there any side-effect? Or I need to add additional code
to avoid some unexpected
situation? Thank you very much!
^ permalink raw reply
* Re: what's the right way to do this in 2.6?
From: Sam Ravnborg @ 2006-03-25 7:05 UTC (permalink / raw)
To: evt; +Cc: linux-kernel
In-Reply-To: <W433413418255631143243608@webmail13>
On Fri, Mar 24, 2006 at 11:40:08PM +0000, evt@texelsoft.com wrote:
> I have two modules that need to share a common utility library. What
> I'd like to do is make the library into a .a and link each module to it.
> 'Twould be also nice if the modules had a dependency so the library
> got built automatically. Thanks for any advice.
Drop the library idea and create a third module.
That's how this is done in several places in the kernel with success.
See Documentation/kbuild/* for how to deal with more than one module.
Sam
^ permalink raw reply
* Re: [PATCH] powerpc: legacy_serial loop cleanup
From: Stephen Rothwell @ 2006-03-25 7:05 UTC (permalink / raw)
To: Michael Neuling; +Cc: michael, linuxppc-dev
In-Reply-To: <20060325044501.D32A267A58@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
On Sat, 25 Mar 2006 15:45:11 +1100 Michael Neuling <mikey@neuling.org> wrote:
>
> Agreed. Updated patch below.
> .
> .
> +static void __init setup_legacy_serial_console(int console)
> +{
> + struct legacy_serial_info *info =
> + &legacy_serial_infos[legacy_serial_console];
Except that you don't want to do that ^ (assuming you meant "console")
> + void __iomem *addr;
> +
> + if (console < 0)
> + return;
before this ^ ... :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] Call get_time() only when necessary in run_hrtimer_queue
From: Thomas Gleixner @ 2006-03-25 7:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Dimitri Sivanich, linux-kernel, mingo, roe, steiner, clameter
In-Reply-To: <20060324142849.5cc27edb.akpm@osdl.org>
On Fri, 2006-03-24 at 14:28 -0800, Andrew Morton wrote:
> This code has been extensively redone in -mm and I am planning on sending
> all that to Linus within a week.
>
> The hrtimer rework in -mm might fix this performance problem, although from
> a quick peek, perhaps not.
>
> So could you please verify that the problem still needs fixing in
> 2.6.16-mm1 and if so, raise a patch against that?
I have a look into it.
tglx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.