).
These are developed and should apply cleanly at least on top the
benchmark cleanup series (might apply cleanly also w/o the benchmark
series, I didn't test).
Ilpo Järvinen (5):
selftests/resctrl: Extend signal handler coverage to unmount on
receiving signal
selftests/resctrl: Remove duplicate feature
On Sat, 23 Feb 2008, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>
> >> -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
> >
> > This is a surprise. I expect that the -mm-only
> > profile-likely-unlikely-macros.patch is the cause of this and mainline
> > doesn't have
On Sat, 23 Feb 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 15:47:10 +0200 "Ilpo J__rvinen" <[EMAIL PROTECTED]> wrote:
>
> > -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
>
> This is a surprise.
It surprised me as well, there were something like 10 bytes I just
couldn't explain
On Sat, 23 Feb 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 15:47:18 +0200 "Ilpo Järvinen" <[EMAIL PROTECTED]> wrote:
>
> > vmlinux.o:
> > 62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
> >
> > ...+ these to lib/jh
On Sat, 23 Feb 2008, Andrew Morton wrote:
On Wed, 20 Feb 2008 15:47:18 +0200 Ilpo Järvinen [EMAIL PROTECTED] wrote:
vmlinux.o:
62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
...+ these to lib/jhash.o:
jhash_3words: 112
jhash2: 276
jhash: 475
On Sat, 23 Feb 2008, Andrew Morton wrote:
On Wed, 20 Feb 2008 15:47:10 +0200 Ilpo J__rvinen [EMAIL PROTECTED] wrote:
-41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
This is a surprise.
It surprised me as well, there were something like 10 bytes I just
couldn't explain in IS_ERR
On Sat, 23 Feb 2008, Andi Kleen wrote:
Andrew Morton [EMAIL PROTECTED] writes:
-41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
This is a surprise. I expect that the -mm-only
profile-likely-unlikely-macros.patch is the cause of this and mainline
doesn't have this problem.
On Wed, 20 Feb 2008, Vlad Yasevich wrote:
> Ilpo Järvinen wrote:
> > I added inline to sctp_add_cmd and appropriate comment there to
> > avoid adding another call into the call chain. This works at least
> > with "gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)". Al
On Wed, 20 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 20 2008 17:27, Patrick McHardy wrote:
> >> Striking. How can this even happen? A callsite which calls
> >>
> >> dev_alloc_skb(n)
> >>
> >> is just equivalent to
> >>
> >> __dev_alloc_skb(n, GFP_ATOMIC);
> >>
> >> which means there's
Codiff stats:
-16420 187 funcs, 103 +, 16523 -, diff: -16420 --- dst_release
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/dst.h | 10 +-
net/core/dst.c| 10 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/net/dst.h b/i
es removed, diff: -6593
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Cc: Vlad Yasevich <[EMAIL PROTECTED]>
---
include/net/sctp/sm.h |8 ++--
net/sctp/command.c| 12 +++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sm.h b
vmlinux.o:
62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
...+ these to lib/jhash.o:
jhash_3words: 112
jhash2: 276
jhash: 475
select for networking code might need a more fine-grained approach.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
drivers/infi
-28162 354 funcs, 3005 +, 31167 -, diff: -28162 --- skb_pull
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 15 +--
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/include
-10976 209 funcs, 123 +, 11099 -, diff: -10976 --- skb_trim
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 16 +---
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/include
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 17 +
net/core/skbuff.c | 18 ++
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include
()
should be rethought but I don't have a clue how to do that.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 20 +---
net/core/skbuff.c | 21 +
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/include
-21593 356 funcs, 2418 +, 24011 -, diff: -21593 --- skb_push
Again, current_text_addr() needs to addressed.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 18 +-
net/core/skbuff.c | 19 +++
2 files changed, 20 inse
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2
()
should be rethought but I don't have a clue how to do that.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 20 +---
net/core/skbuff.c | 21 +
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/include/linux/skbuff.h
-21593 356 funcs, 2418 +, 24011 -, diff: -21593 --- skb_push
Again, current_text_addr() needs to addressed.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 18 +-
net/core/skbuff.c | 19 +++
2 files changed, 20 insertions
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 17 +
net/core/skbuff.c | 18 ++
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include/linux
-28162 354 funcs, 3005 +, 31167 -, diff: -28162 --- skb_pull
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 15 +--
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/include/linux/skbuff.h
-10976 209 funcs, 123 +, 11099 -, diff: -10976 --- skb_trim
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/skbuff.h | 16 +---
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/include/linux/skbuff.h
, diff: -6593
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Cc: Vlad Yasevich [EMAIL PROTECTED]
---
include/net/sctp/sm.h |8 ++--
net/sctp/command.c| 12 +++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index
vmlinux.o:
62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
...+ these to lib/jhash.o:
jhash_3words: 112
jhash2: 276
jhash: 475
select for networking code might need a more fine-grained approach.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
drivers/infiniband
Codiff stats:
-16420 187 funcs, 103 +, 16523 -, diff: -16420 --- dst_release
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/net/dst.h | 10 +-
net/core/dst.c| 10 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/net/dst.h b/include
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2
On Wed, 20 Feb 2008, Jan Engelhardt wrote:
On Feb 20 2008 17:27, Patrick McHardy wrote:
Striking. How can this even happen? A callsite which calls
dev_alloc_skb(n)
is just equivalent to
__dev_alloc_skb(n, GFP_ATOMIC);
which means there's like 4 (or 8 if it's long) bytes
On Wed, 20 Feb 2008, Vlad Yasevich wrote:
Ilpo Järvinen wrote:
I added inline to sctp_add_cmd and appropriate comment there to
avoid adding another call into the call chain. This works at least
with gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13). Alternatively,
__sctp_add_cmd could
On Wed, 13 Feb 2008, linux-os (Dick Johnson) wrote:
>
> On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote:
>
> > They're defined later on in the same file with bodies and
> > nothingin between needs them.
> >
> > Signed-off-by: Ilpo Järvinen <[EMAIL P
They're defined later on in the same file with bodies and
nothingin between needs them.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/coda_linux.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/linux/coda_linux.h b/include
They're defined later on in the same file with bodies and
nothingin between needs them.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/coda_linux.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/linux/coda_linux.h b/include/linux/coda_linux.h
On Wed, 13 Feb 2008, linux-os (Dick Johnson) wrote:
On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote:
They're defined later on in the same file with bodies and
nothingin between needs them.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/coda_linux.h |3
On Fri, 8 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 8 2008 22:34, ael wrote:
> >
> >Sure, I looked there in some depth. But some/most are special purpose or
> > 'locals'. One needs a map for the "main" repositories...
>
> Indeed, a page on kernelnewbies.org with the most important repositories
On Fri, 8 Feb 2008, Jan Engelhardt wrote:
On Feb 8 2008 22:34, ael wrote:
Sure, I looked there in some depth. But some/most are special purpose or
'locals'. One needs a map for the main repositories...
Indeed, a page on kernelnewbies.org with the most important repositories
would be
On Thu, 24 Jan 2008, Ilpo Järvinen wrote:
> And anyway, there were some fackets_out related
> problems reported as well and this doesn't help for that but I think I've
> lost track of who was seeing it due to large number of reports :-), could
> somebody refresh my memory because
t at all.
Effectively, NewReno should always exists after the first
iteration anyway (or immediately if there's already head in
lost_out.
This was fixed earlier in net-2.6.25 but got reverted among other
stuff and I didn't notice that this is still necessary (actually
wasn't even considering this cas
it in
reality was).
This should solve the WARN_ONs in TCP code that as a result of
this triggered multiple times in every place we check for this
invariant.
Special thanks to Dave Young [EMAIL PROTECTED] and
Krishna Kumar2 [EMAIL PROTECTED] for trying with my debug
patches.
Signed-off-by: Ilpo
On Thu, 24 Jan 2008, Ilpo Järvinen wrote:
And anyway, there were some fackets_out related
problems reported as well and this doesn't help for that but I think I've
lost track of who was seeing it due to large number of reports :-), could
somebody refresh my memory because I currently don't
On Wed, 23 Jan 2008, Ilpo Järvinen wrote:
> On Wed, 23 Jan 2008, Dave Young wrote:
>
> > On Jan 23, 2008 3:41 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > >
> > > On Tue, 22 Jan 2008, David Miller wrote:
> > >
> > > > From: "Dav
On Wed, 23 Jan 2008, Dave Young wrote:
> On Jan 23, 2008 3:41 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 22 Jan 2008, David Miller wrote:
> >
> > > From: "Dave Young" <[EMAIL PROTECTED]>
> > > Date: Wed, 23 Jan 20
On Wed, 23 Jan 2008, Dave Young wrote:
On Jan 23, 2008 3:41 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan 22, 2008 6:47 PM, Ilpo Järvinen [EMAIL PROTECTED
On Wed, 23 Jan 2008, Ilpo Järvinen wrote:
On Wed, 23 Jan 2008, Dave Young wrote:
On Jan 23, 2008 3:41 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan
On Tue, 22 Jan 2008, David Miller wrote:
> From: "Dave Young" <[EMAIL PROTECTED]>
> Date: Wed, 23 Jan 2008 09:44:30 +0800
>
> > On Jan 22, 2008 6:47 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > > [PATCH] [TCP]: debug S+L
> >
>
On Tue, 22 Jan 2008, Dave Young wrote:
> On Jan 22, 2008 12:37 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 22, 2008 5:14 AM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mon, 21 Jan 2008, Dave Young wrote:
> > >
>
On Tue, 22 Jan 2008, Dave Young wrote:
On Jan 22, 2008 12:37 PM, Dave Young [EMAIL PROTECTED] wrote:
On Jan 22, 2008 5:14 AM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Mon, 21 Jan 2008, Dave Young wrote:
Please see the kernel messages following,(trigged while using some qemu
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan 22, 2008 6:47 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
[PATCH] [TCP]: debug S+L
Thanks, If there's new findings I will let you know.
Thanks for helping
On Mon, 21 Jan 2008, Dave Young wrote:
> Please see the kernel messages following,(trigged while using some qemu
> session)
> BTW, seems there's some e100 error message as well.
>
> PCI: Setting latency timer of device :00:1b.0 to 64
> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
>
On Mon, 21 Jan 2008, Dave Young wrote:
Please see the kernel messages following,(trigged while using some qemu
session)
BTW, seems there's some e100 error message as well.
PCI: Setting latency timer of device :00:1b.0 to 64
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100:
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
> On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
>
> > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > >
> > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
> > > regression is betwe
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
> On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > The regression is:
> > 1)stoakley with 2 qual-core processors: 11%;
> > 2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
> I have new update on this issue and also cc to netdev maillist.
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
The regression is:
1)stoakley with 2 qual-core processors: 11%;
2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
I have new update on this issue and also cc to netdev maillist.
Thank
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
regression is between 16%~11%.
I tried to use bisect to locate
On Thu, 20 Dec 2007, James Nichols wrote:
> > You'd probably should also investigate the Linux kernel,
> > especially the size and locks of the components of the Sack data
> > structures and what happens to those data structures after Sack is
> > disabled (presumably the Sack data structure is in
On Thu, 20 Dec 2007, James Nichols wrote:
> > I still dont understand.
> >
> > "tcpdump -p -n -s 1600 -c 1" doesnt reveal User data at all.
> >
> > Without any exact data from you, I am afraid nobody can help.
>
> Oh, I didn't see that you specified specific options. I'll still have
> to
On Thu, 20 Dec 2007, James Nichols wrote:
I still dont understand.
tcpdump -p -n -s 1600 -c 1 doesnt reveal User data at all.
Without any exact data from you, I am afraid nobody can help.
Oh, I didn't see that you specified specific options. I'll still have
to anonymize 2000+
On Thu, 20 Dec 2007, James Nichols wrote:
You'd probably should also investigate the Linux kernel,
especially the size and locks of the components of the Sack data
structures and what happens to those data structures after Sack is
disabled (presumably the Sack data structure is in some
On Wed, 19 Dec 2007, Eric Dumazet wrote:
> James Nichols a écrit :
> > On 12/19/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> > > James Nichols a écrit :
> > > > > So you see outgoing SYN packets, but no SYN replies coming from the
> > > > > remote
> > > > > peer ? (you mention ACKS, but the
On Wed, 19 Dec 2007, Eric Dumazet wrote:
James Nichols a écrit :
On 12/19/07, Eric Dumazet [EMAIL PROTECTED] wrote:
James Nichols a écrit :
So you see outgoing SYN packets, but no SYN replies coming from the
remote
peer ? (you mention ACKS, but the first packet received from
On Fri, 14 Dec 2007, Ilpo Järvinen wrote:
> So, I might soon prepare a revert patch for most of the questionable
> TCP parts and ask Dave to apply it (and drop them fully during next
> rebase) unless I suddently figure something out soon which explains
> all/most of the problems,
On Fri, 14 Dec 2007, Ilpo Järvinen wrote:
So, I might soon prepare a revert patch for most of the questionable
TCP parts and ask Dave to apply it (and drop them fully during next
rebase) unless I suddently figure something out soon which explains
all/most of the problems, then return
On Thu, 13 Dec 2007, Cedric Le Goater wrote:
> I got this one while compiling on NFS.
>
> C.
>
> kernel BUG at /home/legoater/linux/2.6.24-rc4-mm1/include/net/tcp.h:1480!
I'm not exactly sure what patches you have applied and which patches are
not, with rc4-mm1 there are two patches (first
On Thu, 13 Dec 2007, Cedric Le Goater wrote:
I got this one while compiling on NFS.
C.
kernel BUG at /home/legoater/linux/2.6.24-rc4-mm1/include/net/tcp.h:1480!
I'm not exactly sure what patches you have applied and which patches are
not, with rc4-mm1 there are two patches (first one was
On Mon, 10 Dec 2007, Ilpo Järvinen wrote:
> Dave, please include this one to net-2.6.25.
...
> --
> [PATCH] [TCP]: Fix fack_count miscountings (multiple places)
I've better version of this coming up, so Dave please don't put this one
into net-2.6.25 (noticed that both the
use it's on
the other list already). These manifest as fackets_out counting
error later on, the second-order effects are very hard to track,
so it may fix all out-standing TCP bug reports.
2) Prev == NULL check was wrong way around
3) Last skb's fack count was incorrectly skipped while() {} loop
Signe
on, the second-order effects are very hard to track,
so it may fix all out-standing TCP bug reports.
2) Prev == NULL check was wrong way around
3) Last skb's fack count was incorrectly skipped while() {} loop
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/net/tcp.h | 22
On Mon, 10 Dec 2007, Ilpo Järvinen wrote:
Dave, please include this one to net-2.6.25.
...
--
[PATCH] [TCP]: Fix fack_count miscountings (multiple places)
I've better version of this coming up, so Dave please don't put this one
into net-2.6.25 (noticed that both the original and the after
On Wed, 5 Dec 2007, David Miller wrote:
> From: Reuben Farrelly <[EMAIL PROTECTED]>
> Date: Thu, 06 Dec 2007 17:59:37 +1100
>
> > On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > > - Lots of device IDs have been removed from the e1000 driver and moved
> > > over
> > > to e1000e. So if your
On Wed, 5 Dec 2007, David Miller wrote:
From: Reuben Farrelly [EMAIL PROTECTED]
Date: Thu, 06 Dec 2007 17:59:37 +1100
On 5/12/2007 4:17 PM, Andrew Morton wrote:
- Lots of device IDs have been removed from the e1000 driver and moved
over
to e1000e. So if your e1000 stops
On Thu, 8 Nov 2007, Rainer Jochem wrote:
> @@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
> *e++ = sizeof(ic_req_params);
> memcpy(e, ic_req_params, sizeof(ic_req_params));
> e += sizeof(ic_req_params);
> +
> + // Send it only if the
On Thu, 8 Nov 2007, Rainer Jochem wrote:
@@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+ // Send it only if the
On Wed, 24 Oct 2007, Adrian Bunk wrote:
> tcp_match_skb_to_sack() can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
[...snip...]
Thanks, I should have noticed that right from the beginning...
Added DaveM to recipients.
--
i.
-
To unsubscribe from this list: send the
On Wed, 24 Oct 2007, Adrian Bunk wrote:
tcp_match_skb_to_sack() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
[...snip...]
Thanks, I should have noticed that right from the beginning...
Added DaveM to recipients.
--
i.
-
To unsubscribe from this list: send the line
On Thu, 18 Oct 2007, Ingo Molnar wrote:
>
> * Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > > it's perfectly legitimate, in fact more robust. So if checkpatch.pl
> > > wants to make any noise about such constructs it should warn about
> > > the _lack_ of curly braces in every multi-line
A good candidate to checkpatch.pl's check list, btw.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
drivers/char/watchdog/wdt.c |3 ++-
drivers/char/watchdog/wdt_pci.c |3 ++-
drivers/scsi/osst.c |6 --
3 files changed, 8 insertions(+), 4 deletions(-)
A good candidate to checkpatch.pl's check list, btw.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
drivers/char/watchdog/wdt.c |3 ++-
drivers/char/watchdog/wdt_pci.c |3 ++-
drivers/scsi/osst.c |6 --
3 files changed, 8 insertions(+), 4 deletions(-)
diff
On Thu, 18 Oct 2007, Ingo Molnar wrote:
* Andy Whitcroft [EMAIL PROTECTED] wrote:
it's perfectly legitimate, in fact more robust. So if checkpatch.pl
wants to make any noise about such constructs it should warn about
the _lack_ of curly braces in every multi-line condition block
On Sat, 13 Oct 2007, Willy Tarreau wrote:
> On Sat, Oct 13, 2007 at 07:50:36PM +0200, Adrian Bunk wrote:
> > On Sat, Oct 13, 2007 at 07:22:14PM +0200, Willy Tarreau wrote:
> > >...
> > > Thanks for your help, I really appreciate it. In fact, I've reviewed them
> > > four, but two of them did not
On Sat, 13 Oct 2007, Willy Tarreau wrote:
On Sat, Oct 13, 2007 at 07:50:36PM +0200, Adrian Bunk wrote:
On Sat, Oct 13, 2007 at 07:22:14PM +0200, Willy Tarreau wrote:
...
Thanks for your help, I really appreciate it. In fact, I've reviewed them
four, but two of them did not apply and the
On Sat, 13 Oct 2007, Willy Tarreau wrote:
> It's possible that new SACK blocks that should trigger new LOST
> markings arrive with new data (which previously made is_dupack
> false). In addition, I think this fixes a case where we get
> a cumulative ACK with enough SACK blocks to trigger the fast
On Sat, 13 Oct 2007, Willy Tarreau wrote:
It's possible that new SACK blocks that should trigger new LOST
markings arrive with new data (which previously made is_dupack
false). In addition, I think this fixes a case where we get
a cumulative ACK with enough SACK blocks to trigger the fast
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 la
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
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.
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
> On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
>
> > I'm currently out of ideas where it could come from...
Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after
all, or in fact, two of them. I'll post patch for this tomorrow...
--
i.
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
> I'm currently out of ideas where it could come from... so lets try
> brute-force checking as your test case is not very high-speed... This
> could hide it though... :-(
>
> Please put the patch below on top of clean rc8-mm2 (it include
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
> got it !
>
> r3-06.test.meiosys.com login: WARNING: at
> /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
> tcp_fastretrans_alert()
>
> Call Trace:
>[] tcp_ack+0xcd6/0x18af
[...snip...]
>
> TCP 0
Hmm, so it's SACK then...
> I
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
got it !
r3-06.test.meiosys.com login: WARNING: at
/home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
tcp_fastretrans_alert()
Call Trace:
IRQ [8040fdc3] tcp_ack+0xcd6/0x18af
[...snip...]
TCP 0
Hmm, so it's SACK
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
I'm currently out of ideas where it could come from... so lets try
brute-force checking as your test case is not very high-speed... This
could hide it though... :-(
Please put the patch below on top of clean rc8-mm2 (it includes the patch
I gave
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
I'm currently out of ideas where it could come from...
Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after
all, or in fact, two of them. I'll post patch for this tomorrow...
--
i.
On Sat, 29 Sep 2007, Cedric Le Goater wrote:
> Ilpo Järvinen wrote:
> > On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> >> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> >>
> >>> I just found that warning in my logs. It seems that it's been
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
>
> > I just found that warning in my logs. It seems that it's been
> > happening since rc7-mm1 at least.
> >
> > WARNING: at /home/legoater/linux/2.6.23-rc8
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
I just found that warning in my logs. It seems that it's been
happening since rc7-mm1 at least.
WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
tcp_fastretrans_alert
On Sat, 29 Sep 2007, Cedric Le Goater wrote:
Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
I just found that warning in my logs. It seems that it's been
happening since rc7-mm1 at least.
WARNING: at /home/legoater
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> Hello !
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
>
> I just found that warning in my logs. It seems that it's been
> happening since rc7-mm1 at least.
>
> Thanks !
>
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
Hello !
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
I just found that warning in my logs. It seems that it's been
happening since rc7-mm1 at least.
Thanks !
C.
On Thu, 27 Sep 2007, Majumder, Rajib wrote:
> We have observed 40ms latency spikes in TCP connections in "burst" type of
> traffic.
> This affects regular TCP sockets.
Are segments being sent full-sized, or is there perhaps some Nagle
component in it as well? I.e., are the applications using
1 - 100 of 125 matches
Mail list logo
