* RE: [ofa-general] [PATCH v3] iw_cxgb3: Support"iwarp-only"interfacestoavoid 4-tuple conflicts.
From: Kanevsky, Arkady @ 2007-10-01 12:34 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, rdreier, linux-kernel, general
In-Reply-To: <46FD7380.6050107@ichips.intel.com>
Sean,
Not so simple.
How does client application knows where to connect?
Does this proposal forces applications to choose
the "right" network?
Currently, MPA or ULP and not applications handle it.
Why would we want to change that?
Sean,
I may be beating the dead horse,
but I recall that one of the main selling points
of RDMA that it magical bust to performance with
no changes applications. Just plug it in an viola,
performances goes up and CPU utilization for network
stack goes does. Win-Win.
Thanks,
Arkady Kanevsky email: arkady@netapp.com
Network Appliance Inc. phone: 781-768-5395
1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195
Waltham, MA 02451 central phone: 781-768-5300
> -----Original Message-----
> From: Sean Hefty [mailto:mshefty@ichips.intel.com]
> Sent: Friday, September 28, 2007 5:35 PM
> To: Kanevsky, Arkady
> Cc: netdev@vger.kernel.org; rdreier@cisco.com;
> linux-kernel@vger.kernel.org; general@lists.openfabrics.org
> Subject: Re: [ofa-general] [PATCH v3] iw_cxgb3:
> Support"iwarp-only"interfacestoavoid 4-tuple conflicts.
>
> Kanevsky, Arkady wrote:
> > Exactly,
> > it forces the burden on administrator.
> > And one will be forced to try one mount for iWARP and it
> does not work
> > issue another one TCP or UDP if it fails.
> > Yack!
> >
> > And server will need to listen on different IP address and simple
> > * will not work since it will need to listen in two
> different domains.
>
> The server already has to call listen twice. Once for the
> rdma_cm and once for sockets. Similarly on the client side,
> connect must be made over rdma_cm or sockets. I really don't
> see any impact on the application for this approach.
>
> We just end up separating the port space based on networking
> addresses, rather than keeping the problem at the transport
> level. If you have an alternate approach that will be
> accepted upstream, feel free to post it.
>
> - Sean
> _______________________________________________
> general mailing list
> general@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>
^ permalink raw reply
* Re: [PATCH 1/1][TCP]: break missing at end of switch statement
From: Al Viro @ 2007-10-01 12:34 UTC (permalink / raw)
To: Gerrit Renker; +Cc: netdev
In-Reply-To: <200710011332.43657@strip-the-willow>
On Mon, Oct 01, 2007 at 01:32:43PM +0100, Gerrit Renker wrote:
> [TCP]: break missing at end of switch statement
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> ---
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -3129,6 +3129,7 @@ static void tcp_reset(struct sock *sk)
> return;
> default:
> sk->sk_err = ECONNRESET;
> + break;
> }
Huh? Why on the Earth would that be a problem?
^ permalink raw reply
* [PATCH 1/1][TCP]: break missing at end of switch statement
From: Gerrit Renker @ 2007-10-01 12:32 UTC (permalink / raw)
To: netdev
[TCP]: break missing at end of switch statement
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3129,6 +3129,7 @@ static void tcp_reset(struct sock *sk)
return;
default:
sk->sk_err = ECONNRESET;
+ break;
}
if (!sock_flag(sk, SOCK_DEAD))
^ permalink raw reply
* [PATCH 4/4] [TCP]: Wrap-safed reordering detection FRTO check
From: Ilpo Järvinen @ 2007-10-01 12:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <11912417841037-git-send-email-ilpo.jarvinen@helsinki.fi>
In case somebody has a suggestion about a better place for this
check, which must guarantee execution "early enough" (i.e,
before the wrap can occur), I'm very open to them.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index cec2611..e22ffe7 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3024,6 +3024,9 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
/* See if we can take anything off of the retransmit queue. */
flag |= tcp_clean_rtx_queue(sk, &seq_rtt);
+ /* Guarantee sacktag reordering detection against wrap-arounds */
+ if (before(tp->frto_highmark, tp->snd_una))
+ tp->frto_highmark = 0;
if (tp->frto_counter)
frto_cwnd = tcp_process_frto(sk, flag);
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/4] [TCP]: Update comment of SACK block validator
From: Ilpo Järvinen @ 2007-10-01 12:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <11912417843258-git-send-email-ilpo.jarvinen@helsinki.fi>
Just came across what RFC2018 states about generation of valid
SACK blocks in case of reneging. Alter comment a bit to point
out clearly.
IMHO, there isn't any reason to change code because the
validation is there for a purpose (counters will inform user
about decision TCP made if this case ever surfaces).
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 135f046..cec2611 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1027,8 +1027,15 @@ static void tcp_update_reordering(struct sock *sk, const int metric,
* SACK block range validation checks that the received SACK block fits to
* the expected sequence limits, i.e., it is between SND.UNA and SND.NXT.
* Note that SND.UNA is not included to the range though being valid because
- * it means that the receiver is rather inconsistent with itself (reports
- * SACK reneging when it should advance SND.UNA).
+ * it means that the receiver is rather inconsistent with itself reporting
+ * SACK reneging when it should advance SND.UNA. Such SACK block this is
+ * perfectly valid, however, in light of RFC2018 which explicitly states
+ * that "SACK block MUST reflect the newest segment. Even if the newest
+ * segment is going to be discarded ...", not that it looks very clever
+ * in case of head skb. Due to potentional receiver driven attacks, we
+ * choose to avoid immediate execution of a walk in write queue due to
+ * reneging and defer head skb's loss recovery to standard loss recovery
+ * procedure that will eventually trigger (nothing forbids us doing this).
*
* Implements also blockage to start_seq wrap-around. Problem lies in the
* fact that though start_seq (s) is before end_seq (i.e., not reversed),
--
1.5.0.6
^ permalink raw reply related
* [PATCH 1/4] [TCP]: No fackets_out/highest_sack tuning when SACK isn't enabled
From: Ilpo Järvinen @ 2007-10-01 12:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <11912417841620-git-send-email-ilpo.jarvinen@helsinki.fi>
This was found due to bug report from Cedric Le Goater though
it turned this turned out to be unrelated bug.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_output.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 94c8011..6199abe 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -660,7 +660,7 @@ static void tcp_set_skb_tso_segs(struct sock *sk, struct sk_buff *skb, unsigned
static void tcp_adjust_fackets_out(struct tcp_sock *tp, struct sk_buff *skb,
int decr)
{
- if (!tp->sacked_out)
+ if (!tp->sacked_out || tcp_is_reno(tp))
return;
if (!before(tp->highest_sack, TCP_SKB_CB(skb)->seq))
@@ -712,7 +712,8 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len, unsigned int mss
TCP_SKB_CB(buff)->end_seq = TCP_SKB_CB(skb)->end_seq;
TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(buff)->seq;
- if (tp->sacked_out && (TCP_SKB_CB(skb)->seq == tp->highest_sack))
+ if (tcp_is_sack(tp) && tp->sacked_out &&
+ (TCP_SKB_CB(skb)->seq == tp->highest_sack))
tp->highest_sack = TCP_SKB_CB(buff)->seq;
/* PSH and FIN should only be set in the second packet. */
@@ -1718,7 +1719,7 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *skb, int m
BUG_ON(tcp_skb_pcount(skb) != 1 ||
tcp_skb_pcount(next_skb) != 1);
- if (WARN_ON(tp->sacked_out &&
+ if (WARN_ON(tcp_is_sack(tp) && tp->sacked_out &&
(TCP_SKB_CB(next_skb)->seq == tp->highest_sack)))
return;
--
1.5.0.6
^ permalink raw reply related
* [PATCH net-2.6.24 0/4]: TCP fixes
From: Ilpo Järvinen @ 2007-10-01 12:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hi Dave,
This fixes the newreno fackets_out case, which turned out to be
not related to the Cedric's case being under investigation. Two
trivial comment patches, and frto with high-speed seqno
wrap-around protection. Compile tested. Please apply to
net-2.6.24.
--
i.
^ permalink raw reply
* [PATCH 2/4] [TCP]: fix comments that got messed up during code move
From: Ilpo Järvinen @ 2007-10-01 12:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <11912417843256-git-send-email-ilpo.jarvinen@helsinki.fi>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2286361..135f046 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1467,8 +1467,9 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
return flag;
}
-/* F-RTO can only be used if TCP has never retransmitted anything other than
- * head (SACK enhanced variant from Appendix B of RFC4138 is more robust here)
+/* If we receive more dupacks than we expected counting segments
+ * in assumption of absent reordering, interpret this as reordering.
+ * The only another reason could be bug in receiver TCP.
*/
static void tcp_check_reno_reordering(struct sock *sk, const int addend)
{
@@ -1516,6 +1517,9 @@ static inline void tcp_reset_reno_sack(struct tcp_sock *tp)
tp->sacked_out = 0;
}
+/* F-RTO can only be used if TCP has never retransmitted anything other than
+ * head (SACK enhanced variant from Appendix B of RFC4138 is more robust here)
+ */
int tcp_use_frto(struct sock *sk)
{
const struct tcp_sock *tp = tcp_sk(sk);
--
1.5.0.6
^ permalink raw reply related
* Re: [RFC] Make TCP prequeue configurable
From: Andi Kleen @ 2007-10-01 12:24 UTC (permalink / raw)
To: David Miller; +Cc: jheffner, shemminger, dada1, netdev
In-Reply-To: <20070928.154031.99471318.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
>
> Furthermore, prequeue puts the stack input processing work into user
> context, which means that the users will be charged more fairly for
> the work that is done for them.
For more details on this people might want to read the old Lazy Receiver
Processing papers: http://www.cs.rice.edu/CS/Systems/LRP/
-Andi
^ permalink raw reply
* Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression
From: Denys @ 2007-10-01 12:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <4700ADB7.7050102@cosmosbay.com>
Not able to compile kernel with patch
drivers/built-in.o: In function `secure_tcp_sequence_number':
(.text+0x3ad02): undefined reference to `__divdi3'
make: *** [.tmp_vmlinux1] Error 1
On Mon, 01 Oct 2007 10:20:07 +0200, Eric Dumazet wrote
> Denys a :
> > Well, i can play a bit more on "live" servers. I have now hot-swap server with
> > full gentoo, where i can rebuild any kernel you want, with any applied patch.
> > But it looks more like not overhead, load becoming high too "spiky", and it is
> > not just permantenly higher. Also it is not normal that all system becoming
> > unresposive (for example ping 127.0.0.1 becoming 300ms for period, when usage
> > softirq jumps to 100%).
> >
> >
> Could you try a pristine 2.6.22.9 and some patch in
> secure_tcp_sequence_number() like :
>
> --- drivers/char/random.c.orig 2007-10-01 10:18:42.000000000 +0200
> +++ drivers/char/random.c 2007-10-01 10:19:58.000000000 +0200
> @@ -1554,7 +1554,7 @@
> * That's funny, Linux has one built in! Use it!
> * (Networks are faster now - should this be increased?)
> */
> - seq += ktime_get_real().tv64;
> + seq += ktime_get_real().tv64 / 1000;
> #if 0
> printk("init_seq(%lx, %lx, %d, %d) = %d\n",
> saddr, daddr, sport, dport, seq);
>
> Thank you
>
> > On Mon, 01 Oct 2007 00:12:59 -0700 (PDT), David Miller wrote
> >
> >> From: Eric Dumazet <dada1@cosmosbay.com>
> >> Date: Mon, 01 Oct 2007 07:59:12 +0200
> >>
> >>
> >>> No problem here on bigger servers, so I CC David Miller and netdev
> >>> on this one. AFAIK do_gettimeofday() and ktime_get_real() should
> >>> use the same underlying hardware functions on PC and no performance
> >>> problem should happen here.
> >>>
> >> One thing that jumps out at me is that on 32-bit (and to a certain
> >> extent on 64-bit) there is a lot of stack accesses and missed
> >> optimizations because all of the work occurs, and gets expanded,
> >> inside of ktime_get_real().
> >>
> >> The timespec_to_ktime() inside of there constructs the ktime_t return
> >> value on the stack, then returns that as an aggregate to the caller.
> >>
> >> That cannot be without some cost.
> >>
> >> ktime_get_real() is definitely a candidate for inlining especially in
> >> these kinds of cases where we'll happily get computations in local
> >> registers instead of all of this on-stack nonsense. And in several
> >> cases (if the caller only needs the tv_sec value, for example)
> >> computations can be elided entirely.
> >>
> >> It would be constructive to experiment and see if this is in fact
> >> part of the problem.
> >>
> >
> >
> > --
> > Denys Fedoryshchenko
> > Technical Manager
> > Virtual ISP S.A.L.
> >
> >
> >
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-10-01 11:49 UTC (permalink / raw)
To: brian.haley, dlstevens; +Cc: davem, netdev, yoshfuji
In-Reply-To: <20070929.100448.41933886.yoshfuji@linux-ipv6.org>
Hello.
In article <20070929.100448.41933886.yoshfuji@linux-ipv6.org> (at Sat, 29 Sep 2007 10:04:48 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:
> In article <OF5FC97D70.5FD0A80A-ON88257365.00025E58-88257365.00048D1E@us.ibm.com> (at Fri, 28 Sep 2007 17:50:38 -0700), David Stevens <dlstevens@us.ibm.com> says:
>
> > Brian,
> > A multicast address should never be the target of a neighbor
> > discovery request; the sender should use the mapping function for all
> > multicasts. So, I'm not sure that your example can ever happen, and it
> > certainly is ok to send ICMPv6 errors to multicast addresses in general.
> > But I don't see that it hurts anything. either (since it should never
> > happen :-)),
> > so I don't particularly object, either.
> > I think it'd also be better if you add the check to be:
> >
> > if (ipv6_addr_type(target) &
> > (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))
> >
> > or something along those lines, rather than reproducing ipv6_addr_type()
> > code
> > separately in a new ipv6_addr_linklocal() function.
I'm fine with the idea of the fix itself.
Please use ipv6_addr_type() so far and convert other users as well
to ipv6_addr_linklocal() in another patch.
Regards,
--yoshfuji
^ permalink raw reply
* Re: Removing DAD in IPv6
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-10-01 11:44 UTC (permalink / raw)
To: xiayang; +Cc: netdev, yoshfuji
In-Reply-To: <1191210807.25398.18.camel@orbit6>
In article <1191210807.25398.18.camel@orbit6> (at Mon, 01 Oct 2007 11:53:27 +0800), Xia Yang <xiayang@ntu.edu.sg> says:
> I would like to ask for help on how to remove or disable the DAD process
> properly, as long as the node can send, receive and forward packets
> immediately after a new IPv6 address is generated. Any pointer is
> appreciated. Thanks a lot in advance!
IFA_F_NODAD address flag might help this.
--yoshfuji
^ permalink raw reply
* Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
From: Karl Meyer @ 2007-10-01 11:42 UTC (permalink / raw)
To: Francois Romieu; +Cc: Michal Piotrowski, linux-kernel, netdev
In-Reply-To: <20070912205025.GA31709@electric-eye.fr.zoreil.com>
Hi,
after reading about issues with the nics on kontron boards I did a
bios upgrade,
but this did not change anything.
However, yesterday the nic (onboard) I used died. No link at all,
after switching to
the next onboard nic I got a NETDEV transmit timeout with that one on
kernel 2.6.22-r2.
It seems the whole thing is a hardware issue. I will try to figure out
with kontron.
Sorry :(
Karl
2007/9/12, Francois Romieu <romieu@fr.zoreil.com>:
> Karl Meyer <adhocrocker@gmail.com> :
> [...]
> > am am looking for this issue for some time now, but there where no
> > errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2
> > officially), I also ran git-bisect (for more information see the older
> > messages in this thread).
>
> 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before
> 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work.
> Thus it is not surprizing that it works.
>
> Any update regarding the patchkit that I sent on 2007/08/16 ?
>
> It would help to narrow the culprit.
>
> --
> Ueimor
>
^ permalink raw reply
* Re: [RFC][IPv6] Export userland ND options through netlink (RDNSS support)
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-10-01 11:42 UTC (permalink / raw)
To: linkfanel; +Cc: netdev, yoshfuji
In-Reply-To: <20070929174720.GA21678@via.ecp.fr>
Hello.
In article <20070929174720.GA21678@via.ecp.fr> (at Sat, 29 Sep 2007 19:47:20 +0200), Pierre Ynard <linkfanel@yahoo.fr> says:
> As discussed before, this patch provides userland with a way to access
> relevant options in Router Advertisements, after they are processed and
> validated by the kernel. Extra options are processed in a generic way;
> this patch only exports RDNSS options described in RFC5006, but support
> to control which options are exported could be easily added.
I basically like this approach at first sight.
> which implies that a userland daemon processing RDNSS options needs a
> way to associate the option to the router that sent it, and fetch its
> lifetime. This kind of information could be included in a header in the
> rtnetlink message (in this version of the patch there is none).
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index dff3192..f69d415 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -97,6 +97,9 @@ enum {
> RTM_SETNEIGHTBL,
> #define RTM_SETNEIGHTBL RTM_SETNEIGHTBL
>
> + RTM_NEWNDUSEROPT = 68,
> +#define RTM_NEWNDUSEROPT RTM_NEWNDUSEROPT
> +
> __RTM_MAX,
Does this imply that we could extend (or reuse) this for all of
NS/NA/RS/RA/Redirect messages? I think you need to include the
code, type and basic semantics of the message.
If this is only for RA, we should say "RTM_NEWRAUSEROPT" or something.
Regards,
--yoshfuji
^ permalink raw reply
* [patch] dm9601: Fix receive MTU
From: Peter Korsgaard @ 2007-10-01 11:36 UTC (permalink / raw)
To: Jeff Garzik, netdev
Please apply to 2.6.23.
---
dm9601 didn't take the ethernet header into account when calculating
RX MTU, causing packets bigger than 1486 to fail.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
drivers/net/usb/dm9601.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-rc8/drivers/net/usb/dm9601.c
===================================================================
--- linux-2.6.23-rc8.orig/drivers/net/usb/dm9601.c
+++ linux-2.6.23-rc8/drivers/net/usb/dm9601.c
@@ -405,7 +405,7 @@
dev->net->ethtool_ops = &dm9601_ethtool_ops;
dev->net->hard_header_len += DM_TX_OVERHEAD;
dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
- dev->rx_urb_size = dev->net->mtu + DM_RX_OVERHEAD;
+ dev->rx_urb_size = dev->net->mtu + ETH_HLEN + DM_RX_OVERHEAD;
dev->mii.dev = dev->net;
dev->mii.mdio_read = dm9601_mdio_read;
--
Bye, Peter Korsgaard
^ permalink raw reply
* [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Patrick McHardy @ 2007-10-01 10:42 UTC (permalink / raw)
To: hadi
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, mcarlson, randy.dunlap, jagana,
general, mchan, tgraf, jeff, sri, shemminger, David Miller
In-Reply-To: <1191178346.6165.29.camel@localhost>
jamal wrote:
> +static inline int
> +dev_requeue_skbs(struct sk_buff_head *skbs, struct net_device *dev,
> + struct Qdisc *q)
> +{
> +
> + struct sk_buff *skb;
> +
> + while ((skb = __skb_dequeue(skbs)) != NULL)
> + q->ops->requeue(skb, q);
->requeue queues at the head, so this looks like it would reverse
the order of the skbs.
^ permalink raw reply
* [PATCH] rtnl_unlock cleanups
From: Denis V. Lunev @ 2007-10-01 9:51 UTC (permalink / raw)
To: davem; +Cc: devel, containers, ebiederm, kaber, kuznet, netdev
There is no need to process outstanding netlink user->kernel packets
during rtnl_unlock now. There is no rtnl_trylock in the rtnetlink_rcv
anymore.
Normal code path is the following:
netlink_sendmsg
netlink_unicast
netlink_sendskb
skb_queue_tail
netlink_data_ready
rtnetlink_rcv
mutex_lock(&rtnl_mutex);
netlink_run_queue(sk, qlen, &rtnetlink_rcv_msg);
mutex_unlock(&rtnl_mutex);
So, it is possible, that packets can be present in the rtnl->sk_receive_queue
during rtnl_unlock, but there is no need to process them at that moment as
rtnetlink_rcv for that packet is pending.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
--- ./net/core/rtnetlink.c.rtnl2 2007-08-26 19:30:38.000000000 +0400
+++ ./net/core/rtnetlink.c 2007-10-01 13:09:03.000000000 +0400
@@ -75,8 +75,6 @@ void __rtnl_unlock(void)
void rtnl_unlock(void)
{
mutex_unlock(&rtnl_mutex);
- if (rtnl && rtnl->sk_receive_queue.qlen)
- rtnl->sk_data_ready(rtnl, 0);
netdev_run_todo();
}
@@ -1319,11 +1317,9 @@ static void rtnetlink_rcv(struct sock *s
unsigned int qlen = 0;
do {
- mutex_lock(&rtnl_mutex);
+ rtnl_lock();
qlen = netlink_run_queue(sk, qlen, &rtnetlink_rcv_msg);
- mutex_unlock(&rtnl_mutex);
-
- netdev_run_todo();
+ rtnl_unlock();
} while (qlen);
}
^ permalink raw reply
* Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
From: Cedric Le Goater @ 2007-10-01 9:26 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Andrew Morton, LKML, Netdev, David Miller
In-Reply-To: <Pine.LNX.4.64.0709292333480.8339@kivilampi-30.cs.helsinki.fi>
Ilpo Järvinen wrote:
> 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/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert()
>>>>>
>>>>> Call Trace:
>>>>> <IRQ> [<ffffffff8040fdc3>] tcp_ack+0xcd6/0x1894
>>>>> ...snip...
>>>> ...Thanks for the report, I'll have look what could still break
>>>> fackets_out...
>>> I think this one is now clear to me, tcp_fragment/collapse adjusts
>>> fackets_out (incorrectly) also for reno flow when there were some dupACKs
>>> that made sacked_out != 0. Could you please try if patch below proves all
>>> them to be of non-SACK origin... In case that's true, it's rather
>>> harmless, I'll send a fix on Monday or so (this would anyway be needed)...
>>> If you find out that them occur with SACK enabled flow, that would be
>>> more interesting and requires more digging...
>> I'm trying now to reproduce this WARNING.
>>
>> It seems that the n/w behaves differently during the week ends. Probably
>> taking a break.
>
> Thanks.
>
> Of course there are other means too to determine if TCP flows do negotiate
> SACK enabled or not. Depending on your test case (which is fully unknown
> to me) they may or may not be usable... At least the value of tcp_sack
> sysctl on both systems or tcpdump catching SYN packets should give that
> detail. ...If you know to which hosts TCP could be connected (and active)
> to, while the WARNING triggers, it's really easy to test what is being
> negotiated as it's unlikely to change at short notice and any TCP flow to
> that host will get us the same information though the WARNING would not be
> triggered with it at this time. Obviously if at least one of the remotes
> is not known or the set ends up being mixture of reno and SACK flows, then
> we'll just have to wait and see which fish we get...
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> [<ffffffff8040fdc3>] tcp_ack+0xcd6/0x18af
[<ffffffff80412b6f>] tcp_rcv_established+0x61f/0x6df
[<ffffffff80254146>] __lock_acquire+0x8a1/0xf1b
[<ffffffff80419d19>] tcp_v4_do_rcv+0x3e/0x394
[<ffffffff8041a68b>] tcp_v4_rcv+0x61c/0x9a9
[<ffffffff803ff1e3>] ip_local_deliver+0x1da/0x2a4
[<ffffffff803ffb4e>] ip_rcv+0x583/0x5c9
[<ffffffff8046d35b>] packet_rcv_spkt+0x19a/0x1a8
[<ffffffff803e081c>] netif_receive_skb+0x2cf/0x2f5
[<ffffffff88042505>] :tg3:tg3_poll+0x65d/0x8a4
[<ffffffff803e09e8>] net_rx_action+0xb8/0x191
[<ffffffff8023a927>] __do_softirq+0x5f/0xe0
[<ffffffff8020c98c>] call_softirq+0x1c/0x28
[<ffffffff8020e9c3>] do_softirq+0x3b/0xb8
[<ffffffff8023aa1e>] irq_exit+0x4e/0x50
[<ffffffff8020e7df>] do_IRQ+0xbd/0xd7
[<ffffffff80209cb9>] mwait_idle+0x0/0x4d
[<ffffffff8020bce6>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff80209cfc>] mwait_idle+0x43/0x4d
[<ffffffff802099fb>] enter_idle+0x22/0x24
[<ffffffff80209c4f>] cpu_idle+0x9d/0xc0
[<ffffffff80476aa1>] rest_init+0x55/0x57
[<ffffffff80630815>] start_kernel+0x2d6/0x2e2
[<ffffffff80630134>] _sinittext+0x134/0x13b
TCP 0
I wasn't doing any particular test on n/w so it took me a while to figure
out how I was triggering the WARNING. Apparently, this is happening when I
run ketchup, but not always. This test machine is behind many firewall &
routers so it might be a reason.
tcpdump gave me this output for a wget on kernel.org :
10:51:14.835981 IP r3-06.test.meiosys.com.40322 > pub2.kernel.org.http: S 737836267:737836267(0) win 5840 <mss 1460,sackOK,timestamp 1309245 0,nop,wscale 7>
10:51:14.975153 IP pub2.kernel.org.http > r3-06.test.meiosys.com.40321: F 524:524(0) ack 166 win 5840
10:51:14.975177 IP r3-06.test.meiosys.com.40321 > pub2.kernel.org.http: . ack 525 win 7504
I'm trying to get the WARNING and the tcpdump output for it but for the
moment, it seems it's beyond my reach :/
Hope it helps !
C.
^ permalink raw reply
* Re: [Devel] Re: [PATCH 2/5] net: Make rtnetlink infrastructure network namespace aware
From: Eric W. Biederman @ 2007-10-01 8:45 UTC (permalink / raw)
To: Denis V. Lunev; +Cc: Patrick McHardy, Linux Containers, netdev, David Miller
In-Reply-To: <4700AF4C.6020509@sw.ru>
"Denis V. Lunev" <den@sw.ru> writes:
> The presence of the message in the queue during rtnl_unlock is quite
> possible as normal user->kernel message processing path for rtnl is the
> following:
>
> netlink_sendmsg
> netlink_unicast
> netlink_sendskb
> skb_queue_tail
> netlink_data_ready
> rtnetlink_rcv
> mutex_lock(&rtnl_mutex);
> netlink_run_queue(sk, qlen, &rtnetlink_rcv_msg);
> mutex_unlock(&rtnl_mutex);
>
> so, the presence of the packet in the rtnl queue on rtnl_unlock is
> normal race with a rtnetlink_rcv for me.
Yes. That is what I saw in practice as well.
Thanks for confirming this.
It happened to reproducible because I had a dhcp client asking
for a list of links in parallel with the actual link coming up
during boot.
Looking at netlink_unicast and netlink_broadcast I am generally
convinced that we can remove the call of sk_data_ready in
rtnl_unlock. I think those are the only two possible paths
through there and I don't see how we could miss a processing a
packet on the way through there.
What would be nice is if we could figure out how to eliminate
this race. As that would allow netlink packets to be processed
synchronously and we could actually use current for security
checks, and for getting the context of the calling process.
Right now we are 99% of the way there but because of the above
race the code must all be written as if netlink packets were coming
in completely asynchronously. Which is unfortunate and a pain.
Eric
^ permalink raw reply
* Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression
From: Eric Dumazet @ 2007-10-01 8:35 UTC (permalink / raw)
Cc: Denys, David Miller, linux-kernel, netdev
In-Reply-To: <4700ADB7.7050102@cosmosbay.com>
Eric Dumazet a écrit :
> Denys a écrit :
>> Well, i can play a bit more on "live" servers. I have now hot-swap
>> server with
>> full gentoo, where i can rebuild any kernel you want, with any
>> applied patch.
>> But it looks more like not overhead, load becoming high too "spiky",
>> and it is
>> not just permantenly higher. Also it is not normal that all system
>> becoming
>> unresposive (for example ping 127.0.0.1 becoming 300ms for period,
>> when usage
>> softirq jumps to 100%).
>>
>>
> Could you try a pristine 2.6.22.9 and some patch in
> secure_tcp_sequence_number() like :
>
> --- drivers/char/random.c.orig 2007-10-01 10:18:42.000000000 +0200
> +++ drivers/char/random.c 2007-10-01 10:19:58.000000000 +0200
> @@ -1554,7 +1554,7 @@
> * That's funny, Linux has one built in! Use it!
> * (Networks are faster now - should this be increased?)
> */
> - seq += ktime_get_real().tv64;
> + seq += ktime_get_real().tv64 / 1000;
> #if 0
> printk("init_seq(%lx, %lx, %d, %d) = %d\n",
> saddr, daddr, sport, dport, seq);
On 32 bits machine, replace the divide by a shift to avoid a linker
error (undefined reference to `__divdi3'):
seq += ktime_get_real().tv64 >> 10;
^ permalink raw reply
* Re: [Devel] Re: [PATCH 2/5] net: Make rtnetlink infrastructure network namespace aware
From: Denis V. Lunev @ 2007-10-01 8:26 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric W. Biederman, Linux Containers, netdev, David Miller
In-Reply-To: <46FFC34A.3020701@trash.net>
Patrick McHardy wrote:
> Eric W. Biederman wrote:
>> Patrick McHardy <kaber@trash.net> writes:
>>
>>
>>> Maybe I can save you some time: we used to do down_trylock()
>>> for the rtnl mutex, so senders would simply return if someone
>>> else was already processing the queue *or* the rtnl was locked
>>> for some other reason. In the first case the process already
>>> processing the queue would also process the new messages, but
>>> if it the rtnl was locked for some other reason (for example
>>> during module registration) the message would sit in the
>>> queue until the next rtnetlink sendmsg call, which is why
>>> rtnl_unlock does queue processing. Commit 6756ae4b changed
>>> the down_trylock to mutex_lock, so senders will now simply wait
>>> until the mutex is released and then call netlink_run_queue
>>> themselves. This means its not needed anymore.
>>
>> Sounds reasonable.
>>
>> I started looking through the code paths and I currently cannot
>> see anything that would leave a message on a kernel rtnl socket.
>>
>> However I did a quick test adding a WARN_ON if there were any messages
>> found in the queue during rtnl_unlock and I found this code path
>> getting invoked from linkwatch_event. So there is clearly something I
>> don't understand, and it sounds at odds just a bit from your
>> description.
>
>
> That sounds like a bug. Did you place the WARN_ON before or after
> the mutex_unlock()?
The presence of the message in the queue during rtnl_unlock is quite
possible as normal user->kernel message processing path for rtnl is the
following:
netlink_sendmsg
netlink_unicast
netlink_sendskb
skb_queue_tail
netlink_data_ready
rtnetlink_rcv
mutex_lock(&rtnl_mutex);
netlink_run_queue(sk, qlen, &rtnetlink_rcv_msg);
mutex_unlock(&rtnl_mutex);
so, the presence of the packet in the rtnl queue on rtnl_unlock is
normal race with a rtnetlink_rcv for me.
Regards,
Den
^ permalink raw reply
* Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression
From: Eric Dumazet @ 2007-10-01 8:20 UTC (permalink / raw)
To: Denys; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <20071001080339.M21850@nuclearcat.com>
Denys a écrit :
> Well, i can play a bit more on "live" servers. I have now hot-swap server with
> full gentoo, where i can rebuild any kernel you want, with any applied patch.
> But it looks more like not overhead, load becoming high too "spiky", and it is
> not just permantenly higher. Also it is not normal that all system becoming
> unresposive (for example ping 127.0.0.1 becoming 300ms for period, when usage
> softirq jumps to 100%).
>
>
Could you try a pristine 2.6.22.9 and some patch in
secure_tcp_sequence_number() like :
--- drivers/char/random.c.orig 2007-10-01 10:18:42.000000000 +0200
+++ drivers/char/random.c 2007-10-01 10:19:58.000000000 +0200
@@ -1554,7 +1554,7 @@
* That's funny, Linux has one built in! Use it!
* (Networks are faster now - should this be increased?)
*/
- seq += ktime_get_real().tv64;
+ seq += ktime_get_real().tv64 / 1000;
#if 0
printk("init_seq(%lx, %lx, %d, %d) = %d\n",
saddr, daddr, sport, dport, seq);
Thank you
> On Mon, 01 Oct 2007 00:12:59 -0700 (PDT), David Miller wrote
>
>> From: Eric Dumazet <dada1@cosmosbay.com>
>> Date: Mon, 01 Oct 2007 07:59:12 +0200
>>
>>
>>> No problem here on bigger servers, so I CC David Miller and netdev
>>> on this one. AFAIK do_gettimeofday() and ktime_get_real() should
>>> use the same underlying hardware functions on PC and no performance
>>> problem should happen here.
>>>
>> One thing that jumps out at me is that on 32-bit (and to a certain
>> extent on 64-bit) there is a lot of stack accesses and missed
>> optimizations because all of the work occurs, and gets expanded,
>> inside of ktime_get_real().
>>
>> The timespec_to_ktime() inside of there constructs the ktime_t return
>> value on the stack, then returns that as an aggregate to the caller.
>>
>> That cannot be without some cost.
>>
>> ktime_get_real() is definitely a candidate for inlining especially in
>> these kinds of cases where we'll happily get computations in local
>> registers instead of all of this on-stack nonsense. And in several
>> cases (if the caller only needs the tv_sec value, for example)
>> computations can be elided entirely.
>>
>> It would be constructive to experiment and see if this is in fact
>> part of the problem.
>>
>
>
> --
> Denys Fedoryshchenko
> Technical Manager
> Virtual ISP S.A.L.
>
>
>
^ permalink raw reply
* Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression
From: Denys @ 2007-10-01 8:07 UTC (permalink / raw)
To: David Miller, dada1; +Cc: linux-kernel, netdev
In-Reply-To: <20071001.001259.28812610.davem@davemloft.net>
Well, i can play a bit more on "live" servers. I have now hot-swap server with
full gentoo, where i can rebuild any kernel you want, with any applied patch.
But it looks more like not overhead, load becoming high too "spiky", and it is
not just permantenly higher. Also it is not normal that all system becoming
unresposive (for example ping 127.0.0.1 becoming 300ms for period, when usage
softirq jumps to 100%).
On Mon, 01 Oct 2007 00:12:59 -0700 (PDT), David Miller wrote
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Mon, 01 Oct 2007 07:59:12 +0200
>
> > No problem here on bigger servers, so I CC David Miller and netdev
> > on this one. AFAIK do_gettimeofday() and ktime_get_real() should
> > use the same underlying hardware functions on PC and no performance
> > problem should happen here.
>
> One thing that jumps out at me is that on 32-bit (and to a certain
> extent on 64-bit) there is a lot of stack accesses and missed
> optimizations because all of the work occurs, and gets expanded,
> inside of ktime_get_real().
>
> The timespec_to_ktime() inside of there constructs the ktime_t return
> value on the stack, then returns that as an aggregate to the caller.
>
> That cannot be without some cost.
>
> ktime_get_real() is definitely a candidate for inlining especially in
> these kinds of cases where we'll happily get computations in local
> registers instead of all of this on-stack nonsense. And in several
> cases (if the caller only needs the tv_sec value, for example)
> computations can be elided entirely.
>
> It would be constructive to experiment and see if this is in fact
> part of the problem.
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression
From: David Miller @ 2007-10-01 7:12 UTC (permalink / raw)
To: dada1; +Cc: nuclearcat, linux-kernel, netdev
In-Reply-To: <47008CB0.7010808@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 01 Oct 2007 07:59:12 +0200
> No problem here on bigger servers, so I CC David Miller and netdev
> on this one. AFAIK do_gettimeofday() and ktime_get_real() should
> use the same underlying hardware functions on PC and no performance
> problem should happen here.
One thing that jumps out at me is that on 32-bit (and to a certain
extent on 64-bit) there is a lot of stack accesses and missed
optimizations because all of the work occurs, and gets expanded,
inside of ktime_get_real().
The timespec_to_ktime() inside of there constructs the ktime_t return
value on the stack, then returns that as an aggregate to the caller.
That cannot be without some cost.
ktime_get_real() is definitely a candidate for inlining especially in
these kinds of cases where we'll happily get computations in local
registers instead of all of this on-stack nonsense. And in several
cases (if the caller only needs the tv_sec value, for example)
computations can be elided entirely.
It would be constructive to experiment and see if this is in fact part
of the problem.
^ permalink raw reply
* Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression
From: Eric Dumazet @ 2007-10-01 5:59 UTC (permalink / raw)
To: Denys; +Cc: linux-kernel, David S. Miller, Linux Netdev List
In-Reply-To: <20070930223503.M8966@nuclearcat.com>
Denys a écrit :
> Hi
>
> I got
>
> pi linux-git # git bisect bad
> Bisecting: 0 revisions left to test after this
> [f85958151900f9d30fa5ff941b0ce71eaa45a7de] [NET]: random functions can use
> nsec resolution instead of usec
>
> I will make sure and will try to reverse this patch on 2.6.22
>
> But it seems "that's it".
Well... thats interesting...
No problem here on bigger servers, so I CC David Miller and netdev on this one.
AFAIK do_gettimeofday() and ktime_get_real() should use the same underlying
hardware functions on PC and no performance problem should happen here.
(relevant part of this patch :
@ -1521,7 +1515,6 @@ __u32 secure_ip_id(__be32 daddr)
__u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
__be16 sport, __be16 dport)
{
- struct timeval tv;
__u32 seq;
__u32 hash[4];
struct keydata *keyptr = get_keyptr();
@@ -1543,12 +1536,11 @@ __u32 secure_tcp_sequence_number(__be32 saddr, __be32
daddr,
* As close as possible to RFC 793, which
* suggests using a 250 kHz clock.
* Further reading shows this assumes 2 Mb/s networks.
- * For 10 Mb/s Ethernet, a 1 MHz clock is appropriate.
+ * For 10 Gb/s Ethernet, a 1 GHz clock is appropriate.
* That's funny, Linux has one built in! Use it!
* (Networks are faster now - should this be increased?)
*/
- do_gettimeofday(&tv);
- seq += tv.tv_usec + tv.tv_sec * 1000000;
+ seq += ktime_get_real().tv64;
Thank you for doing this research.
>
>
> On Sun, 30 Sep 2007 14:25:37 +1000, Nick Piggin wrote
>> Hi Denys, thanks for reporting (btw. please reply-to-all when
>> replying on lkml).
>>
>> You say that SLAB is better than SLUB on an otherwise identical
>> kernel, but I didn't see if you quantified the actual numbers? It
>> sounds like there is still a regression with SLAB?
>>
>> On Monday 01 October 2007 03:48, Eric Dumazet wrote:
>>> Denys a :
>>>> I've moved recently one of my proxies(squid and some compressing
>>>> application) from 2.6.21 to 2.6.22, and notice huge performance drop. I
>>>> think this is important, cause it can cause serious regression on some
>>>> other workloads like busy web-servers and etc.
>>>>
>>>> After some analysis of different options i can bring more exact numbers:
>>>>
>>>> 2.6.21 able to process 500-550 requests/second and 15-20 Mbit/s of
>>>> traffic, and working great without any slowdown or instability.
>>>>
>>>> 2.6.22 able to process only 250-300 requests and 8-10 Mbit/s of traffic,
>>>> ssh and console is "freezing" (there is delay even for typing
>>>> characters).
>>>>
>>>> Both proxies is on identical hardware(Sun Fire X4100),
>>>> configuration(small system, LFS-like, on USB flash), different only
>>>> kernel.
>>>>
>>>> I tried to disable/enable various options and optimisations - it doesn't
>>>> change anything, till i reach SLUB/SLAB option.
>>>>
>>>> I've loaded proxy configuration to gentoo PC with 2.6.22 (then upgraded
>>>> it to 2.6.23-rc8), and having same effect.
>>>> Additionally, when load reaching maximum i can notice whole system
>>>> slowdown, for example ssh and scp takes much more time to run, even i do
>>>> nice -n -5 for them.
>>>>
>>>> But even choosing 2.6.23-rc8+SLAB i noticed same "freezing" of ssh (and
>>>> sure it slowdown other kind of network performance), but much less
>>>> comparing with SLUB. On top i am seeing ksoftirqd taking almost 100%
>>>> (sometimes ksoftirqd/0, sometimes ksoftirqd/1).
>>>>
>>>> I tried also different tricks with scheduler (/proc/sys/kernel/sched*),
>>>> but it's also didn't help.
>>>>
>>>> When it freezes it looks like:
>>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>>> 7 root 15 -5 0 0 0 R 64 0.0 2:47.48 ksoftirqd/1
>>>> 5819 root 20 0 134m 130m 596 R 57 3.3 4:36.78 globax
>>>> 5911 squid 20 0 1138m 1.1g 2124 R 26 28.9 2:24.87 squid
>>>> 10 root 15 -5 0 0 0 S 1 0.0 0:01.86 events/1
>>>> 6130 root 20 0 3960 2416 1592 S 0 0.1 0:08.02 oprofiled
>>>>
>>>>
>>>> Oprofile results:
>>>>
>>>>
>>>> Thats oprofile with 2.6.23-rc8 - SLUB
>>>>
>>>> 73918 21.5521 check_bytes
>>>> 38361 11.1848 acpi_pm_read
>>>> 14077 4.1044 init_object
>>>> 13632 3.9747 ip_send_reply
>>>> 8486 2.4742 __slab_alloc
>>>> 7199 2.0990 nf_iterate
>>>> 6718 1.9588 page_address
>>>> 6716 1.9582 tcp_v4_rcv
>>>> 6425 1.8733 __slab_free
>>>> 5604 1.6339 on_freelist
>>>>
>>>>
>>>> Thats oprofile with 2.6.23-rc8 - SLAB
>>>>
>>>> CPU: AMD64 processors, speed 2592.64 MHz (estimated)
>>>> Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
>>>> unit mask of 0x00 (No unit mask) count 100000
>>>> samples % symbol name
>>>> 138991 14.0627 acpi_pm_read
>>>> 52401 5.3018 tcp_v4_rcv
>>>> 48466 4.9037 nf_iterate
>>>> 38043 3.8491 __slab_alloc
>>>> 34155 3.4557 ip_send_reply
>>>> 20963 2.1210 ip_rcv
>>>> 19475 1.9704 csum_partial
>>>> 19084 1.9309 kfree
>>>> 17434 1.7639 ip_output
>>>> 17278 1.7481 netif_receive_skb
>>>> 15248 1.5428 nf_hook_slow
>>>>
>>>> My .config is at http://www.nuclearcat.com/.config (there is SPARSEMEM
>>>> enabled, it doesn't make any noticeable difference)
>>>>
>>>> Please CC me on reply, i am not in list.
>>> Could you try with SLUB but disabling CONFIG_SLUB_DEBUG ?
>
>
> --
> Denys Fedoryshchenko
> Technical Manager
> Virtual ISP S.A.L.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox