From: Sridhar Samudrala [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 23:37:37 -0800 (PST)
Instead, you seem to be suggesting in_emergency to be set dynamically
when we are about to run out of ATOMIC memory. Is this right?
Not when we run out, but rather when we reach some low water mark, the
On Thu, 2005-12-15 at 00:21 -0800, David S. Miller wrote:
From: Sridhar Samudrala [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 23:37:37 -0800 (PST)
Instead, you seem to be suggesting in_emergency to be set dynamically
when we are about to run out of ATOMIC memory. Is this right?
Not when we
Also, all this stuff is just a band aid because linux OOM behavior is so
fucked up.
In our internal discussions, characterizing this as OOM came
up a lot, and I don't think of it as that at all. OOM is exactly what the
scheme is trying to avoid!
The actual situation we have in mind is a swap
On Wed, Dec 14, 2005 at 03:39:50PM -0800, David S. Miller wrote:
From: Hoerdt Mickael [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 23:38:56 +0100
As implemented now, the default memory allocated in net.core.optmem_max
permit
to join up to 320 (S,G) channels per sockets (for IPv6, each
On Dec 15, 2005, at 03:21, David S. Miller wrote:
Not when we run out, but rather when we reach some low water mark,
the critical sockets would still use GFP_ATOMIC memory but only
critical sockets would be allowed to do so.
But even this has faults, consider the IPSEC scenerio I mentioned,
When processes request memory through any subsystem, their memory
priority would be passed through the kernel layers to the allocator,
along with any associated information about how to free the memory in
a low-memory condition. As a result, I could configure my database
to have a
David S. Miller [EMAIL PROTECTED] wrote on 12/15/2005 12:58:05 AM:
From: David Stevens [EMAIL PROTECTED]
Date: Thu, 15 Dec 2005 00:44:52 -0800
In our internal discussions
I really wish this hadn't been discussed internally before being
implemented. Any such internal discussions are
@@ -1281,7 +1345,18 @@ static int is_in(struct ifmcaddr6 *pmc,
case MLD2_MODE_IS_EXCLUDE:
if (gdeleted || sdeleted)
return 0;
- return !((pmc-mca_flags MAF_GSQUERY)
!psf-sf_gsresp);
+ if (!((pmc-mca_flags
Mitchell Blank Jr wrote:
James Courtier-Dutton wrote:
When I had the conversation with Matt at KS, the problem we were trying
to solve was Memory pressure with network attached swap space.
s/swap space/writable filesystems/
You can hit these problems even if you have no swap. Too much of
You are using the wrong hammer to crack your nut.
You should instead approach your problem of why the ARP entry gets lost.
For example, you could give as critical priority to your TCP session,
but that still won't cure your ARP problem.
I would suggest that the best way to cure your arp
Performance optimizations, changes in these areas:
- RX and TX checksum offload
- correct maximum MTU
- don't use TX interrupts anymore, use a timer instead
- remove some superfluous barriers
- improve RX RAM full handling
From: Utz Bacher [EMAIL PROTECTED]
From: Jens Osterkamp [EMAIL
On Thursday 15 December 2005 19:55, Kyle Moffett wrote:
On Dec 15, 2005, at 03:21, David S. Miller wrote:
Not when we run out, but rather when we reach some low water mark,
the critical sockets would still use GFP_ATOMIC memory but only
critical sockets would be allowed to do so.
But
On Dec 15, 2005, at 07:45, Con Kolivas wrote:
I have some basic process-that-called the memory allocator link in
the -ck tree already which alters how aggressively memory is
reclaimed according to priority. It does not affect out of memory
management but that could be added to said
On Thursday 15 December 2005 23:58, Kyle Moffett wrote:
On Dec 15, 2005, at 07:45, Con Kolivas wrote:
I have some basic process-that-called the memory allocator link in
the -ck tree already which alters how aggressively memory is
reclaimed according to priority. It does not affect out of
On Thu, 2005-15-12 at 12:47 +0100, Arjan van de Ven wrote:
You are using the wrong hammer to crack your nut.
You should instead approach your problem of why the ARP entry gets lost.
For example, you could give as critical priority to your TCP session,
but that still won't cure your ARP
On Thu, 2005-12-15 at 08:00 -0500, jamal wrote:
On Thu, 2005-15-12 at 12:47 +0100, Arjan van de Ven wrote:
You are using the wrong hammer to crack your nut.
You should instead approach your problem of why the ARP entry gets lost.
For example, you could give as critical priority to
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
On Thu, 2005-15-12 at 05:57 +0100, Krzysztof Oledzki wrote:
Addedd CC: to the [EMAIL PROTECTED] mailing list.
And I added Shoichi Sakane to the CC. He is responsible for bringing
use new SA feature to BSD to begin with and is one of
On Thu, Dec 15, 2005 at 01:47:25PM +0100, Jens Osterkamp wrote:
The driver incorrectly used dma_addr_t to describe
HW structures and consequently broke when that type
was changed in 2.6.15-rc.
This changed spidernet to use u32 for 32 bit HW defined
structure elements.
actually this
Hallo,
When I boot a kernel with iommu=force (this forces all pci_map_sgs
through the K8 aperture) and slab debugging on a Nforce4 x86-64
system the network corrupts data very quickly. Even when just
sshing somewhere ssh quickly aborts with MAC errors etc.
Reverting only forcedeth.c to the one
On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote:
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
What is not true?;- CISCO doesnt hardcode 30 secs as the time between
soft and hard expiry? Or what is said with CISCO not sending IKE
delete? AFAIK, both are true.
On Thu, Dec 15, 2005 at 10:27:02AM -0500, jamal wrote:
On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote:
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
What is not true?;- CISCO doesnt hardcode 30 secs as the time between
soft and hard expiry? Or what is said with
On Thu, Dec 15, 2005 at 04:29:04PM +0100, Andi Kleen wrote:
Hallo,
When I boot a kernel with iommu=force (this forces all pci_map_sgs
through the K8 aperture) and slab debugging on a Nforce4 x86-64
system the network corrupts data very quickly. Even when just
sshing somewhere ssh quickly
On Thu, Dec 15, 2005 at 11:40:08AM -0500, John W. Linville wrote:
On Thu, Dec 15, 2005 at 04:29:04PM +0100, Andi Kleen wrote:
Hallo,
When I boot a kernel with iommu=force (this forces all pci_map_sgs
through the K8 aperture) and slab debugging on a Nforce4 x86-64
system the network
On Thu, 2005-15-12 at 17:11 +0100, Krzysztof Oledzki wrote:
On Thu, 15 Dec 2005, jamal wrote:
[..]
Thats one interpretation. The other is in the same section and says:
Deletion of the old SA is dependent on local security policy.
Please notice - there are two SA: incomming and outgoing.
On Thu, 2005-15-12 at 17:23 +0100, VANHULLEBUS Yvan wrote:
On Thu, Dec 15, 2005 at 10:27:02AM -0500, jamal wrote:
On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote:
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
What is not true?;- CISCO doesnt hardcode 30 secs as the
Also have to handle out of memory condition on resume.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -3416,8 +3416,8 @@ static int skge_resume(struct pci_dev *p
struct net_device *dev = hw-dev[i];
On Thu, Dec 15, 2005 at 05:50:50PM +0100, Andi Kleen wrote:
On Thu, Dec 15, 2005 at 11:40:08AM -0500, John W. Linville wrote:
On Thu, Dec 15, 2005 at 04:29:04PM +0100, Andi Kleen wrote:
Hallo,
When I boot a kernel with iommu=force (this forces all pci_map_sgs
through the K8
On Thu, 15 Dec 2005, jamal wrote:
Agree. It is a _workaround_;- A good one in my opinion. Given that it
works for CISCOs, a very large piece of the problem is resolved, no?
No, again, it does not help. I explained it in my previous mail.
It will help 100% of the time _if you know_ you have
Change if (pmc-mca_sfcount[MCAST_INCLUDE]) to if
(psf-sf_count[MCAST_INCLUDE]) ?
Yes, good catch! I'll re-roll and resubmit.
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Given the pretty extensive modifications necessary, do you have any
useful benchmark data to show that this is a win. Previous zero
copy (like page flipping) has not be merged because it did not
prove to be a net gain.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
Hi,
Resending to make sure this doesn't fall through the cracks. The
following patch applies to 2.6 and fixes a memory leak.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
* net/bridge/br_netfilter.c (br_nf_pre_routing, br_nf_pre_routing_ipv6) :
Call nf_bridge_put() before allocating a new
From: John W. Linville [EMAIL PROTECTED]
Date: Thu, 15 Dec 2005 15:21:37 -0500
Interesting... FWIW the FC4.netdev.6 kernel seems to be working fine
on (a yet-to-be-released box), which is an x86_64 (AMD) box w/
forcedeth hardware. The forcedeth.c in the FC4.netdev.6 kernel is
identical to
Hi,
We use dual 3.06 GHz Xeon PC servers, with 1 GB memory, 133-MHz/64-bit
PCI-X bus, and Intel PRO/10GbE 10-GigE NIC, as 10-GigE network performance
measurement and troubleshooting systems. With the 2.6.12.6 kernel we
get consistently excellent network performance, both TCP and UDP.
Here's a
Oops. I forgot to attach my 2.6.12.6 kernel config.
-Bill
config-2.6.12.bz2
Description: BZip2 compressed data
From: jamal [EMAIL PROTECTED]
Date: Thu, 15 Dec 2005 15:56:52 -0500
Refer to Herberts solution and see if that solves the problem.
I think the kernel is definitely within it's rights to interpret
section 4.3 of RFC2408 the way that it does.
And I bet that whoever wrote those paragraphs used
On Thu, Dec 15, 2005 at 01:58:41PM -0800, David S. Miller wrote:
From: John W. Linville [EMAIL PROTECTED]
Date: Thu, 15 Dec 2005 15:21:37 -0500
Interesting... FWIW the FC4.netdev.6 kernel seems to be working fine
on (a yet-to-be-released box), which is an x86_64 (AMD) box w/
forcedeth
Hi Stephen,
Replace cube root algorithim with a faster version using Newton-Raphson.
Surprisingly, doing the scaled div64_64 is faster than a true 64 bit
division on 64 bit CPU's.
Interesting, what cpu was this on? Was there much difference between the
two methods?
Anton
-
To unsubscribe
On Thu, 15 Dec 2005, David S. Miller wrote:
1) I don't understand how a routing cache flush fixes the problem.
The routing cache flush only marks non-IPSEC cached routes as
invalid, not IPSEC ones.
New IPsec SA is used for communication between new src/dst (previously
unseend) pair
Fixup callers who're checking for is_multicast || is_broadcast, that's no
longer necessary. Change !is_multicast callers to use is_unicast.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
drivers/net/wireless/ipw2200.c | 15 +--
net/ieee80211/ieee80211_rx.c |5 ++---
Everything I've found on the 'net says that any MAC address with 0x1 in
byte 0 is a multicast address. Which obviously includes the broadcast address.
I think is_multicast_ether_addr() should implement that logic, if not we
should call it something else, otherwise we're asking for confusion.
I've
It appears that it is getting CPU starved for some reason (note the
43%/40% transmitter CPU usage versus the 99%/99% CPU usage for the
2.6.12.6 case).
What happens when you turn off tso in ethtool?
-Andi
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
From: Krzysztof Oledzki [EMAIL PROTECTED]
Date: Fri, 16 Dec 2005 01:04:47 +0100 (CET)
It looks like XFRM caches that information, so kernel does need to search
whole SADB for each packet and this is the reason why usage of old SA is
observed. This is my theory only, someone who wrote XFRM
On Fri, 16 Dec 2005, Andi Kleen wrote:
It appears that it is getting CPU starved for some reason (note the
43%/40% transmitter CPU usage versus the 99%/99% CPU usage for the
2.6.12.6 case).
What happens when you turn off tso in ethtool?
Thanks!!! That did the trick.
[EMAIL PROTECTED]
From: Bill Fink [EMAIL PROTECTED]
Date: Thu, 15 Dec 2005 20:35:32 -0500
chance% nuttcp -w2m 192.168.88.8
6299.0625 MB / 10.01 sec = 5278.6065 Mbps 100 %TX 74 %RX
chance% nuttcp -r -w2m 192.168.88.8
6221.3125 MB / 10.01 sec = 5213.2026 Mbps 100 %TX 71 %RX
And a full test I just did
From: David S. Miller [EMAIL PROTECTED]
Date: Thu, 15 Dec 2005 17:04:56 -0800 (PST)
I'm trying to see if there is a clever way to make existing SA
entries get invalidated upon insertion of a new SA which shadows
them.
To illustrate why this is a hard problem, I've drawn an
extensive diagram
The following is an extremely inefficient way to make new
SAs visible immediately. It is just for example purposes.
We just flush out all the cached bundles any time we insert
a new SA state.
Krzysztof, can you at least verify that this makes your
problem go away? Thanks.
diff --git
On Thu, Dec 15, 2005 at 06:54:21PM -0600, Michael Ellerman wrote:
+ /* XXX Why are we checking for 0xff here ? */
+ return (addr[0] == 0xff) || (!is_multicast_ether_addr(addr)
+ !is_zero_ether_addr(addr));
That is a good question...what does a MAC address like
On Thu, 2005-12-15 at 00:21 -0800, David S. Miller wrote:
From: Sridhar Samudrala [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 23:37:37 -0800 (PST)
Instead, you seem to be suggesting in_emergency to be set dynamically
when we are about to run out of ATOMIC memory. Is this right?
Not when we
From: David S. Miller [EMAIL PROTECTED]
Date: Thu, 15 Dec 2005 17:52:54 -0800 (PST)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 7cf48aa..25dd8f4 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
Sorry, that patch was incomplete, please try this one instead:
On Thu, Dec 15, 2005 at 08:35:32PM -0500, Bill Fink wrote:
On Fri, 16 Dec 2005, Andi Kleen wrote:
It appears that it is getting CPU starved for some reason (note the
43%/40% transmitter CPU usage versus the 99%/99% CPU usage for the
2.6.12.6 case).
What happens when you turn off
Some more testing shows that even the 2.6.14 driver eventually
causes slab debugging BUGs() like
--- [cut here ] - [please bite here ] -
Kernel BUG at /home/andi/lsrc/linux-2.6.15rc5-git4/mm/slab.c:2307
invalid operand: [1] PREEMPT SMP
CPU 3
Modules linked in:
[revised patch to fix is_in() sfcount typo - thanks to Yan Zheng]
Dave,
I tested these together, but let me know if you want me to
split these into a few pieces, though they'll probably conflict with
each other. :-)
The below jumbo patch fixes the following problems in MLDv2.
1) Add
On Thu, 15 Dec 2005 21:10:03 -0500
John W. Linville [EMAIL PROTECTED] wrote:
On Thu, Dec 15, 2005 at 06:54:21PM -0600, Michael Ellerman wrote:
+ /* XXX Why are we checking for 0xff here ? */
+ return (addr[0] == 0xff) || (!is_multicast_ether_addr(addr)
+
On Fri, 16 Dec 2005 03:26:31 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Dec 15, 2005 at 08:35:32PM -0500, Bill Fink wrote:
On Fri, 16 Dec 2005, Andi Kleen wrote:
It appears that it is getting CPU starved for some reason (note the
43%/40% transmitter CPU usage versus the
54 matches
Mail list logo
