* Re: [BUG] IPv6 recursive locking
From: David Miller @ 2008-02-18 2:43 UTC (permalink / raw)
To: dlezcano; +Cc: Kristof, netdev
In-Reply-To: <47B87D2B.7040400@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Sun, 17 Feb 2008 19:30:03 +0100
> I think this bug was introduced by the commit:
>
> 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> "[NDISC]: Fix race in generic address resolution".
Yep and I'll revert this for now.
^ permalink raw reply
* Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
From: Grant Grundler @ 2008-02-18 3:21 UTC (permalink / raw)
To: Ondrej Zary; +Cc: jgarzik, Linux Kernel, netdev, grundler
In-Reply-To: <200801302123.07783.linux@rainbow-software.org>
On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
> On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
> > Hello,
> > I was having problems with these FreedomLine cards with Linux before but
> > tested it thoroughly today. This card uses DEC 21041 chip and has TP and
> > BNC connectors:
> >
> > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
> > 21041 [Tulip Pass 3] [1011:0014] (rev 21)
> >
> >
> > de2104x driver was loaded automatically by udev and card seemed to work.
> > Until I disconnected the TP cable and putting it back after a while. The
> > driver then switched to (non-existing) AUI port and remained there. I tried
> > to set media to TP using ethtool - and the whole kernel crashed because of
> > BUG_ON(de_is_running(de));
> > in de_set_media(). Seems that the driver is unable to stop the DMA in
> > de_stop_rxtx().
The BUG_ON() is probably fine normally. But the media selection sounds broken.
It's possible to select the wrong media type with 21040 chip but shouldn't
be possible with 21041. For 21040 support, see de21040_get_media_info().
But de21041_get_srom_info() is expected to determine which media
types are supported from SEPROM "media blocks". My guess is that code
is broken since it seems to work with de405 driver. If you care to
work the difference, I'd be happy to make a patch to fix that up.
Also, from code review, DE2104X driver still has a few places with
potential PCI MMIO Write posting issues. Specifically, I was looking
in de_stop_hw() and de_set_media(). Several other bits of code correctly
flush MMIO writes: e.g. tulip_read_eeprom().
> > I commented out AUI detection in the driver - this time it switched to BNC
> > after unplugging the cable and remained there. I also attempted to reset
> > the chip when de_stop_rxtx failed but failed to do it.
You'd have to basically hardcode only one media type and it's corresponding
parameters.
> > Then I found that there's de4x5 driver which supports the same cards as
> > de2104x (and some other too) - and this one works fine! I can plug and
> > unplug the cable and even change between TP and BNC ports just by
> > unplugging one and plugging the other cable in. Unfortunately, this driver
> > is blacklisted by default - at least in Slackware and Debian.
ISTR there was a time when tulip would compete with de4x5 for devices.
tulip is the preferred driver. That's clearly no longer the case
and perhaps both distro's need to revisit this.
> > The question is: why does de2104x exist? Does it work better with some
> > hardware?
de2104x is a "work in progress".
That's why it's marked "EXPERIMENTAL" in the Kconfig file.
> > BTW. Found that the problem exist at least since 2003:
> > http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
>
> Does the de2104x driver work correctly for anyone?
No idea. I've only used tulip driver.
thanks for the bug report,
grant
^ permalink raw reply
* Re: [resend] [PATCH] IPv4: Reset scope when changing address
From: David Miller @ 2008-02-18 6:22 UTC (permalink / raw)
To: bjorn; +Cc: netdev
In-Reply-To: <87bq6hazvo.fsf@obelix.mork.no>
From: Bjørn_Mork <bjorn@mork.no>
Date: Sat, 16 Feb 2008 12:45:31 +0100
> <#part type=text/plain nofile=yes>
> Any comments on this? Apparently introduced in 2.1.68, so there's not
> much hurry. But I'd still like to hear whether that analysis is correct
> or not...
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="==-=-="
Please clear up all of the inline mime tag stuff in your
outgoing emails. Your description and patch is very difficult
to read because of this.
Thank you.
^ permalink raw reply
* Re: [PATCH 1/3] fib_trie: move statistics to debugfs
From: David Miller @ 2008-02-18 6:26 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20080213195929.781366896@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 13 Feb 2008 11:58:06 -0800
> Don't want /proc/net/fib_trie and /proc/net/fib_triestat to become
> permanent kernel space ABI issues, so move to the safer confines of debugfs.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Stephen, the cat is already out of the bag. We already export this
thing so if you want to export different stuff you'll have to provide
it via some other means, somewhere else.
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix tcp_v4_send_synack() comment
From: David Miller @ 2008-02-18 6:29 UTC (permalink / raw)
To: katterjohn; +Cc: netdev
In-Reply-To: <47B3937F.6010106@gmail.com>
From: Kris Katterjohn <katterjohn@gmail.com>
Date: Wed, 13 Feb 2008 19:03:59 -0600
> Hey everyone,
>
> I've attached a patch that fixes the comment above tcp_v4_send_synack()
> in ipv4/tcp_ipv4.c.
>
> Signed-off-by: Kris Katterjohn <katterjohn@gmail.com>
Applied, thanks.
Please "-p1" root your patches in the future.
^ permalink raw reply
* Re: [PATCH][AX25] ax25_out: check skb for NULL in ax25_kick()
From: David Miller @ 2008-02-18 6:31 UTC (permalink / raw)
To: jarkao2; +Cc: jann, f6bvp, ralf, netdev
In-Reply-To: <20080213115607.GB2867@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Wed, 13 Feb 2008 11:56:07 +0000
> [AX25] ax25_out: check skb for NULL in ax25_kick()
>
> According to some OOPS reports ax25_kick tries to clone NULL skbs
> sometimes. It looks like a race with ax25_clear_queues(). Probably
> there is no need to add more than a simple check for this yet.
> Another report suggested there are probably also cases where ax25
> ->paclen == 0 can happen in ax25_output(); this wasn't confirmed
> during testing but let's leave this debugging check for some time.
>
> Reported-and-tested-by: Jann Traschewski <jann@gmx.de>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied, thanks Jarek.
^ permalink raw reply
* Re: [PATCH 1/2][NETLABEL]: Shrink the genl-ops registration code.
From: David Miller @ 2008-02-18 6:33 UTC (permalink / raw)
To: paul.moore; +Cc: xemul, netdev
In-Reply-To: <200802130833.09096.paul.moore@hp.com>
From: Paul Moore <paul.moore@hp.com>
Date: Wed, 13 Feb 2008 08:33:08 -0500
> On Wednesday 13 February 2008 6:09:44 am Pavel Emelyanov wrote:
> > Turning them to array and registration in a loop saves
> > 80 lines of code and ~300 bytes from text section.
> >
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Definitely an improvement, thank you.
>
> Acked-by: Paul Moore <paul.moore@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2][NETLABEL]: Move some initialization code into __init section.
From: David Miller @ 2008-02-18 6:34 UTC (permalink / raw)
To: paul.moore; +Cc: xemul, netdev
In-Reply-To: <200802130837.17249.paul.moore@hp.com>
From: Paul Moore <paul.moore@hp.com>
Date: Wed, 13 Feb 2008 08:37:16 -0500
> On Wednesday 13 February 2008 6:12:06 am Pavel Emelyanov wrote:
> > Everything that is called from netlbl_init() can be marked with
> > __init. This moves 620 bytes from .text section to .text.init one.
> >
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> I ran into problems with __init and __exit once because I didn't fully
> understand their impact; this caused me to be rather hesitant to make use of
> them. However, you seem to know what you are doing and these look like
> reasonable changes to me so I'll ack this patch and if we do run into a
> problem the fix should be pretty trivial.
Yes, this stuff can be non-trivial at best on some days :-)
> I appreciate you taking the time to find these optimizations, thanks again.
>
> Acked-by: Paul Moore <paul.moore@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] [IPV6]: Fix hardcoded removing of old module code
From: David Miller @ 2008-02-18 6:35 UTC (permalink / raw)
To: wangchen; +Cc: yoshfuji, herbert, rusty, netdev
In-Reply-To: <47B2BA6B.2000003@cn.fujitsu.com>
From: Wang Chen <wangchen@cn.fujitsu.com>
Date: Wed, 13 Feb 2008 17:37:47 +0800
> Rusty hardcoded the old module code.
> We can remove it now.
>
> Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
Applied, thanks for removing this turd.
^ permalink raw reply
* Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: David Miller @ 2008-02-18 7:28 UTC (permalink / raw)
Cc: linux-kernel, kaber, netdev
In-Reply-To: <E1JPn6W-0002J2-5x@luxik.cdi.cz>
From: Martin Devera <devik@cdi.cz>
Date: Fri, 15 Feb 2008 00:02:56 +0100
> From: Martin Devera <devik@cdi.cz>
>
> HTB is event driven algorithm and part of its work is to apply
> scheduled events at proper times. It tried to defend itself from
> livelock by processing only limited number of events per dequeue.
> Because of faster computers some users already hit this hardcoded
> limit.
> This patch uses loops_per_jiffy variable to limit event processing
> up to single jiffy interval and then delay remainder to other
> jiffy.
>
> Signed-off-by: Martin Devera <devik@cdi.cz>
I think we would be wise to use something other than loops_per_jiffy.
Depending upon the loop calibration method used by a particular
architecture it can me one of many different things.
Some platforms don't even make use of it and thus leave it at it's
default value of "1<<12", so using it as a heuristic here is arbitrary
at best.
^ permalink raw reply
* Re: [RFC PATCH] [XFRM]: Fix ordering issue in xfrm_dst_hash_transfer().
From: David Miller @ 2008-02-18 7:29 UTC (permalink / raw)
To: sdecugis; +Cc: yoshfuji, herbert, kazunori, yoshfuji, netdev
In-Reply-To: <47B526E0.3040807@hongo.wide.ad.jp>
From: Sebastien Decugis <sdecugis@hongo.wide.ad.jp>
Date: Fri, 15 Feb 2008 14:45:04 +0900
> It works, thank you!
>
> Acked-by: Sebastien Decugis <sdecugis@hongo.wide.ad.jp>
Patch applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/3] Support arbitrary initial TCP timestamps
From: David Miller @ 2008-02-18 7:33 UTC (permalink / raw)
To: ggriffin.kernel; +Cc: netdev, linux-kernel
In-Reply-To: <1203097630-13237-1-git-send-email-ggriffin.kernel@gmail.com>
From: Glenn Griffin <ggriffin.kernel@gmail.com>
Date: Fri, 15 Feb 2008 09:47:08 -0800
> Introduce the ability to send arbitrary initial tcp timestamps that are not
> tied directly to jiffies. The basic conecpt is every tcp_request_sock and
> tcp_sock now has a ts_off offset that represents the difference between
> tcp_time_stamp and the timestamp we send and expect to
> receive.
>
> This has the advantage of not divulging system information (uptime)
> depending on the policy chosen for the initial timestamps.
>
> A policy where ts_off is always set to zero should produce no change in
> behavior. The policy implemented is not intended for real use, but just as
> a simple example. A realistic example would probably be similar to the tcp
> init sequence generator.
>
> Signed-off-by: Glenn Griffin <ggriffin.kernel@gmail.com>
Adding yet another member to the already bloated tcp_sock structure to
implement this is too high a cost.
I would instead prefer that there be some global random number
calculated when the first TCP socket is created, and use that as a
global offset. You can even recompute it every few hours if you
like.
We do similar things already elsewhere.
^ permalink raw reply
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: David Miller @ 2008-02-18 7:35 UTC (permalink / raw)
To: joe; +Cc: kaber, bruno, netdev, jgarzik, linux-wireless, linville
In-Reply-To: <1203097370.21308.18.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Fri, 15 Feb 2008 09:42:50 -0800
> On Fri, 2008-02-15 at 02:58 -0800, David Miller wrote:
> > From: Bruno Randolf <bruno@thinktube.com>
> > Date: Fri, 15 Feb 2008 19:48:05 +0900
> > > is there any chance to include a macro like this for printing mac
> > addresses?
> > > its advantage is that it can be used without the need to declare
> > buffers for
> > > print_mac(), for example:
> > We specifically removed this sort of thing, please don't
> > add it back.
>
> Remove direct use of MAC_FMT
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] Remove MAC_FMT
From: David Miller @ 2008-02-18 7:35 UTC (permalink / raw)
To: joe; +Cc: bruno, netdev, jgarzik, linux-wireless, linville
In-Reply-To: <1203097375.21308.20.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Fri, 15 Feb 2008 09:42:55 -0800
> MAC_FMT is no longer used
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 1/2] bluetooth : put hci dev after del conn
From: Dave Young @ 2008-02-18 7:55 UTC (permalink / raw)
To: marcel; +Cc: netdev, davem, bluez-devel, linux-kernel
Move hci_dev_put to del_conn to avoid hci dev going away before hci conn.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
---
net/bluetooth/hci_conn.c | 1 -
net/bluetooth/hci_sysfs.c | 5 ++++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff -upr linux/net/bluetooth/hci_conn.c linux.new/net/bluetooth/hci_conn.c
--- linux/net/bluetooth/hci_conn.c 2008-02-16 06:38:56.000000000 +0800
+++ linux.new/net/bluetooth/hci_conn.c 2008-02-16 06:54:17.000000000 +0800
@@ -260,7 +260,6 @@ int hci_conn_del(struct hci_conn *conn)
tasklet_enable(&hdev->tx_task);
skb_queue_purge(&conn->data_q);
hci_conn_del_sysfs(conn);
- hci_dev_put(hdev);
return 0;
}
diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2008-02-16 06:38:56.000000000 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2008-02-16 06:54:17.000000000 +0800
@@ -333,15 +333,18 @@ static int __match_tty(struct device *de
static void del_conn(struct work_struct *work)
{
- struct device *dev;
struct hci_conn *conn = container_of(work, struct hci_conn, work);
+ struct hci_dev *hdev = conn->hdev;
+ struct device *dev;
while (dev = device_find_child(&conn->dev, NULL, __match_tty)) {
device_move(dev, NULL);
put_device(dev);
}
+
device_del(&conn->dev);
put_device(&conn->dev);
+ hci_dev_put(hdev);
}
void hci_conn_del_sysfs(struct hci_conn *conn)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* [PATCH 2/2] bluetooth : do not move child device other than rfcomm
From: Dave Young @ 2008-02-18 7:58 UTC (permalink / raw)
To: marcel; +Cc: netdev, davem, bluez-devel, linux-kernel
hci conn child devices other than rfcomm tty should not be moved here.
This is my lost, thanks for Barnaby's reporting and testing.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
---
net/bluetooth/hci_sysfs.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2008-02-16 06:38:56.000000000 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2008-02-17 15:45:15.000000000 +0800
@@ -320,15 +320,14 @@ void hci_conn_add_sysfs(struct hci_conn
queue_work(btaddconn, &conn->work);
}
+/*
+ * The rfcomm tty device will possibly retain even when conn
+ * is down, and sysfs doesn't support move zombie device,
+ * so we should move the device before conn device is destroyed.
+ */
static int __match_tty(struct device *dev, void *data)
{
- /* The rfcomm tty device will possibly retain even when conn
- * is down, and sysfs doesn't support move zombie device,
- * so we should move the device before conn device is destroyed.
- * Due to the only child device of hci_conn dev is rfcomm
- * tty_dev, here just return 1
- */
- return 1;
+ return !strncmp(dev->bus_id, "rfcomm", 6);
}
static void del_conn(struct work_struct *work)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: Martin Devera @ 2008-02-18 8:03 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, kaber, netdev
In-Reply-To: <20080217.232829.222344360.davem@davemloft.net>
>> up to single jiffy interval and then delay remainder to other
>> jiffy.
>>
>> Signed-off-by: Martin Devera <devik@cdi.cz>
>
> I think we would be wise to use something other than loops_per_jiffy.
>
> Depending upon the loop calibration method used by a particular
> architecture it can me one of many different things.
>
> Some platforms don't even make use of it and thus leave it at it's
aha, ok, I'm not so informed about crossplatform issues.
I was also thining about looking at jiffies value and stop once
it is startjiffy+2, but with NO_HZ introduction, are jiffies
still incremented ?
^ permalink raw reply
* Re: tbench regression in 2.6.25-rc1
From: Zhang, Yanmin @ 2008-02-18 8:12 UTC (permalink / raw)
To: David Miller; +Cc: dada1, herbert, linux-kernel, netdev
In-Reply-To: <20080215.152200.145584182.davem@davemloft.net>
On Fri, 2008-02-15 at 15:22 -0800, David Miller wrote:
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Fri, 15 Feb 2008 15:21:48 +0100
>
> > On linux-2.6.25-rc1 x86_64 :
> >
> > offsetof(struct dst_entry, lastuse)=0xb0
> > offsetof(struct dst_entry, __refcnt)=0xb8
> > offsetof(struct dst_entry, __use)=0xbc
> > offsetof(struct dst_entry, next)=0xc0
> >
> > So it should be optimal... I dont know why tbench prefers __refcnt being
> > on 0xc0, since in this case lastuse will be on a different cache line...
> >
> > Each incoming IP packet will need to change lastuse, __refcnt and __use,
> > so keeping them in the same cache line is a win.
> >
> > I suspect then that even this patch could help tbench, since it avoids
> > writing lastuse...
>
> I think your suspicions are right, and even moreso
> it helps to keep __refcnt out of the same cache line
> as input/output/ops which are read-almost-entirely :-
I think you are right. The issue is these three variables sharing the same cache line
with input/output/ops.
> )
>
> I haven't done an exhaustive analysis, but it seems that
> the write traffic to lastuse and __refcnt are about the
> same. However if we find that __refcnt gets hit more
> than lastuse in this workload, it explains the regression.
I also think __refcnt is the key. I did a new testing by adding 2 unsigned long
pading before lastuse, so the 3 members are moved to next cache line. The performance is
recovered.
How about below patch? Almost all performance is recovered with the new patch.
Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
---
--- linux-2.6.25-rc1/include/net/dst.h 2008-02-21 14:33:43.000000000 +0800
+++ linux-2.6.25-rc1_work/include/net/dst.h 2008-02-21 14:36:22.000000000 +0800
@@ -52,11 +52,10 @@ struct dst_entry
unsigned short header_len; /* more space at head required */
unsigned short trailer_len; /* space to reserve at tail */
- u32 metrics[RTAX_MAX];
- struct dst_entry *path;
-
- unsigned long rate_last; /* rate limiting for ICMP */
unsigned int rate_tokens;
+ unsigned long rate_last; /* rate limiting for ICMP */
+
+ struct dst_entry *path;
#ifdef CONFIG_NET_CLS_ROUTE
__u32 tclassid;
@@ -70,10 +69,12 @@ struct dst_entry
int (*output)(struct sk_buff*);
struct dst_ops *ops;
-
- unsigned long lastuse;
+
+ u32 metrics[RTAX_MAX];
+
atomic_t __refcnt; /* client references */
int __use;
+ unsigned long lastuse;
union {
struct dst_entry *next;
struct rtable *rt_next;
^ permalink raw reply
* Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: David Miller @ 2008-02-18 8:17 UTC (permalink / raw)
To: devik; +Cc: linux-kernel, kaber, netdev
In-Reply-To: <47B93BE8.7010905@cdi.cz>
From: Martin Devera <devik@cdi.cz>
Date: Mon, 18 Feb 2008 09:03:52 +0100
> aha, ok, I'm not so informed about crossplatform issues.
> I was also thining about looking at jiffies value and stop once
> it is startjiffy+2, but with NO_HZ introduction, are jiffies
> still incremented ?
There should always be at least once cpu tasked with incrementing
jiffies. Lots of stuff would break if not :-)
^ permalink raw reply
* [PATCH resend] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
From: Christian Borntraeger @ 2008-02-18 9:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: virtualization, netdev
In-Reply-To: <47B069E0.9040905@us.ibm.com>
Am Montag, 11. Februar 2008 schrieb Anthony Liguori:
> The reset support is in Linus's tree so we should try to push it for -rc2.
You are right. My repository was borked. will push it to Jeff Garzik. Thanks
Jeff can you schedule this fix into your network driver updates? Thanks
---
With the latest virtio_reset patches I got the following oops:
Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000
Oops: 0004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 Not tainted 2.6.24zlive-guest-10577-g63f5307-dirty #168
Process swapper (pid: 0, task: 000000000f866040, ksp: 000000000f86fd78)
Krnl PSW : 0404100180000000 000000000047598a (skb_recv_done+0x52/0x98)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000000 000000000efd0e60 0000000000000001
0000000000000000 000000000f866040 0000000000000000 0000000000000000
00000000008de4c8 0000000000001237 0000000000001237 000000000f977dd8
0000000000000020 00000000001132bc 000000000f977e08 000000000f977dd8
Krnl Code: 000000000047597c: e31040300004 lg %r1,48(%r4)
0000000000475982: b9040001 lgr %r0,%r1
0000000000475986: b9810003 ogr %r0,%r3
>000000000047598a: eb1040300030 csg %r1,%r0,48(%r4)
0000000000475990: a744fff9 brc 4,475982
0000000000475994: a7110001 tmll %r1,1
0000000000475998: a7840009 brc 8,4759aa
000000000047599c: e340b0b80004 lg %r4,184(%r11)
Call Trace:
([<000001500f978000>] 0x1500f978000)
[<00000000004779a6>] vring_interrupt+0x72/0x88
[<0000000000491d9c>] kvm_extint_handler+0x34/0x44
[<000000000010d2d4>] do_extint+0xc0/0xfc
[<0000000000113b5a>] ext_no_vtime+0x1c/0x20
[<000000000010a0b6>] cpu_idle+0x21a/0x230
([<000000000010a096>] cpu_idle+0x1fa/0x230)
[<000000000057dfe4>] start_secondary+0xa0/0xb4
We must initialize vdev->priv before we use the notify hypercall as
vdev->priv is used in skb_recv_done. So lets move the assignment of
vdev->priv before we call try_fill_recv.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/net/virtio_net.c
===================================================================
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -361,6 +361,7 @@ static int virtnet_probe(struct virtio_d
netif_napi_add(dev, &vi->napi, virtnet_poll, napi_weight);
vi->dev = dev;
vi->vdev = vdev;
+ vdev->priv = vi;
/* We expect two virtqueues, receive then send. */
vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
@@ -395,7 +396,6 @@ static int virtnet_probe(struct virtio_d
}
pr_debug("virtnet: registered device %s\n", dev->name);
- vdev->priv = vi;
return 0;
unregister:
^ permalink raw reply
* e1000: Question about polling
From: Badalian Vyacheslav @ 2008-02-18 9:18 UTC (permalink / raw)
To: netdev
Hello all.
Interesting think:
Have PC that do NAT. Bandwidth about 600 mbs.
Have 4 CPU (2xCoRe 2 DUO "HT OFF" 3.2 HZ).
irqbalance in kernel is off.
nat2 ~ # cat /proc/irq/217/smp_affinity
00000001
nat2 ~ # cat /proc/irq/218/smp_affinity
00000003
Load SI on CPU0 and CPU1 is about 90%
Good... try do
echo ffffffff > /proc/irq/217/smp_affinity
echo ffffffff > /proc/irq/218/smp_affinity
Get 100% SI at CPU0
Question Why?
I listen that if use IRQ from 1 netdevice to 1 CPU i can get 30%
perfomance... but i have 4 CPU... i must get more perfomance if i cat
"ffffffff" to smp_affinity.
picture looks liks this:
0-3 CPU get over 50% SI.... bandwith up.... 55% SI... bandwith up...
100% SI on CPU0....
I remember patch to fix problem like it... patched function
e1000_clean... kernel on pc have this patch (2.6.24-rc7-git2)... e1000
driver work much better (i up to 1.5-2x bandwidth before i get 100% SI),
but i think that it not get 100% that it can =)
Thanks for answers and sorry for my English
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-18 9:56 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Q Klein, ossthema, Greg KH, apw, linux-kernel,
linuxppc-dev, Christoph Raisch, Badari Pulavarty, netdev, tklein
In-Reply-To: <1203094538.8142.23.camel@nimitz.home.sr71.net>
[-- Attachment #1.1: Type: text/plain, Size: 2256 bytes --]
Dave Hansen <haveblue@us.ibm.com> wrote on 15.02.2008 17:55:38:
> I've been thinking about that, and I don't think you really *need* to
> keep a comprehensive map like that.
>
> When the memory is in a particular configuration (range of memory
> present along with unique set of holes) you get a unique ehea_bmap
> configuration. That layout is completely predictable.
>
> So, if at any time you want to figure out what the ehea_bmap address for
> a particular *Linux* virtual address is, you just need to pretend that
> you're creating the entire ehea_bmap, use the same algorithm and figure
> out host you would have placed things, and use that result.
>
> Now, that's going to be a slow, crappy linear search (but maybe not as
> slow as recreating the silly thing). So, you might eventually run into
> some scalability problems with a lot of packets going around. But, I'd
> be curious if you do in practice.
Up to 14 addresses translation per packet (sg_list) might be required on
the
transmit side. On receive side it is only 1. Most packets require only
very few
translations (1 or sometimes more) translations. However, with more then
700.000
packets per second this approach does not seem reasonable from performance
perspective when memory is fragmented as you described.
>
> The other idea is that you create a mapping that is precisely 1:1 with
> kernel memory. Let's say you have two sections present, 0 and 100. You
> have a high_section_index of 100, and you vmalloc() a 100 entry array.
>
> You need to create a *CONTIGUOUS* ehea map? Create one like this:
>
> EHEA_VADDR->Linux Section
> 0->0
> 1->0
> 2->0
> 3->0
> ...
> 100->100
>
> It's contiguous. Each area points to a valid Linux memory address.
> It's also discernable in O(1) to what EHEA address a given Linux address
> is mapped. You just have a couple of duplicate entries.
This has a serious issues with constraint I mentions in the previous mail:
"- MRs can have a maximum size of the memory available under linux"
The requirement is not met that the memory region must not be
larger then the available memory for that partition. The "create MR"
H_CALL
will fails (we tried this and discussed with FW development)
Regards,
Jan-Bernd & Christoph
[-- Attachment #1.2: Type: text/html, Size: 4038 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-18 10:00 UTC (permalink / raw)
To: linuxppc-dev
Cc: Dave Hansen, Christoph Raisch, Thomas Q Klein, ossthema,
Jan-Bernd Themann, Greg KH, apw, linux-kernel, Badari Pulavarty,
netdev, tklein
In-Reply-To: <1203094538.8142.23.camel@nimitz.home.sr71.net>
switching to proper mail client...
Dave Hansen <haveblue@us.ibm.com> wrote on 15.02.2008 17:55:38:
> I've been thinking about that, and I don't think you really *need* to
> keep a comprehensive map like that.
>
> When the memory is in a particular configuration (range of memory
> present along with unique set of holes) you get a unique ehea_bmap
> configuration. That layout is completely predictable.
>
> So, if at any time you want to figure out what the ehea_bmap address for
> a particular *Linux* virtual address is, you just need to pretend that
> you're creating the entire ehea_bmap, use the same algorithm and figure
> out host you would have placed things, and use that result.
>
> Now, that's going to be a slow, crappy linear search (but maybe not as
> slow as recreating the silly thing). So, you might eventually run into
> some scalability problems with a lot of packets going around. But, I'd
> be curious if you do in practice.
Up to 14 addresses translation per packet (sg_list) might be required on
the transmit side. On receive side it is only 1. Most packets require only
very few translations (1 or sometimes more) translations. However,
with more then 700.000 packets per second this approach does not seem
reasonable from performance perspective when memory is fragmented as you
described.
>
> The other idea is that you create a mapping that is precisely 1:1 with
> kernel memory. Let's say you have two sections present, 0 and 100. You
> have a high_section_index of 100, and you vmalloc() a 100 entry array.
>
> You need to create a *CONTIGUOUS* ehea map? Create one like this:
>
> EHEA_VADDR->Linux Section
> 0->0
> 1->0
> 2->0
> 3->0
> ...
> 100->100
>
> It's contiguous. Each area points to a valid Linux memory address.
> It's also discernable in O(1) to what EHEA address a given Linux address
> is mapped. You just have a couple of duplicate entries.
This has a serious issues with constraint I mentions in the previous mail:
"- MRs can have a maximum size of the memory available under linux"
The requirement is not met that the memory region must not be
larger then the available memory for that partition. The "create MR"
H_CALL will fails (we tried this and discussed with FW development)
Regards,
Jan-Bernd & Christoph
^ permalink raw reply
* Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: Martin Devera @ 2008-02-18 10:08 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, kaber, netdev
In-Reply-To: <20080218.001736.124204016.davem@davemloft.net>
David Miller wrote:
> From: Martin Devera <devik@cdi.cz>
> Date: Mon, 18 Feb 2008 09:03:52 +0100
>
>> aha, ok, I'm not so informed about crossplatform issues.
>> I was also thining about looking at jiffies value and stop once
>> it is startjiffy+2, but with NO_HZ introduction, are jiffies
>> still incremented ?
>
> There should always be at least once cpu tasked with incrementing
> jiffies. Lots of stuff would break if not :-)
>
Aha ok, so that when (at least one) cpu is busy then I can count on
jiffies incrementing via do_timer, can't I ?
So that I'd remove the loop limit altogether but limiting it to
1 or 2 jiffies to prevent livelock.
Like
max_jiff = jiffies+2; /* not +1 at we could be at +0.9999 now */
while (jiffies<max_jiff) do_hard_potentionaly_long_work();
if (more_work) schedule_to_next_jiffie();
This will keep event queue work load under 66% of system load which
seems reasonable to me.
Would you accept such solution ?
^ permalink raw reply
* Re: tbench regression in 2.6.25-rc1
From: Eric Dumazet @ 2008-02-18 10:11 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: David Miller, herbert, linux-kernel, netdev
In-Reply-To: <1203322358.3027.200.camel@ymzhang>
On Mon, 18 Feb 2008 16:12:38 +0800
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com> wrote:
> On Fri, 2008-02-15 at 15:22 -0800, David Miller wrote:
> > From: Eric Dumazet <dada1@cosmosbay.com>
> > Date: Fri, 15 Feb 2008 15:21:48 +0100
> >
> > > On linux-2.6.25-rc1 x86_64 :
> > >
> > > offsetof(struct dst_entry, lastuse)=0xb0
> > > offsetof(struct dst_entry, __refcnt)=0xb8
> > > offsetof(struct dst_entry, __use)=0xbc
> > > offsetof(struct dst_entry, next)=0xc0
> > >
> > > So it should be optimal... I dont know why tbench prefers __refcnt being
> > > on 0xc0, since in this case lastuse will be on a different cache line...
> > >
> > > Each incoming IP packet will need to change lastuse, __refcnt and __use,
> > > so keeping them in the same cache line is a win.
> > >
> > > I suspect then that even this patch could help tbench, since it avoids
> > > writing lastuse...
> >
> > I think your suspicions are right, and even moreso
> > it helps to keep __refcnt out of the same cache line
> > as input/output/ops which are read-almost-entirely :-
> I think you are right. The issue is these three variables sharing the same cache line
> with input/output/ops.
>
> > )
> >
> > I haven't done an exhaustive analysis, but it seems that
> > the write traffic to lastuse and __refcnt are about the
> > same. However if we find that __refcnt gets hit more
> > than lastuse in this workload, it explains the regression.
> I also think __refcnt is the key. I did a new testing by adding 2 unsigned long
> pading before lastuse, so the 3 members are moved to next cache line. The performance is
> recovered.
>
> How about below patch? Almost all performance is recovered with the new patch.
>
> Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
>
> ---
>
> --- linux-2.6.25-rc1/include/net/dst.h 2008-02-21 14:33:43.000000000 +0800
> +++ linux-2.6.25-rc1_work/include/net/dst.h 2008-02-21 14:36:22.000000000 +0800
> @@ -52,11 +52,10 @@ struct dst_entry
> unsigned short header_len; /* more space at head required */
> unsigned short trailer_len; /* space to reserve at tail */
>
> - u32 metrics[RTAX_MAX];
> - struct dst_entry *path;
> -
> - unsigned long rate_last; /* rate limiting for ICMP */
> unsigned int rate_tokens;
> + unsigned long rate_last; /* rate limiting for ICMP */
> +
> + struct dst_entry *path;
>
> #ifdef CONFIG_NET_CLS_ROUTE
> __u32 tclassid;
> @@ -70,10 +69,12 @@ struct dst_entry
> int (*output)(struct sk_buff*);
>
> struct dst_ops *ops;
> -
> - unsigned long lastuse;
> +
> + u32 metrics[RTAX_MAX];
> +
> atomic_t __refcnt; /* client references */
> int __use;
> + unsigned long lastuse;
> union {
> struct dst_entry *next;
> struct rtable *rt_next;
>
>
Well, after this patch, we grow dst_entry by 8 bytes :
sizeof(struct dst_entry)=0xd0
offsetof(struct dst_entry, input)=0x68
offsetof(struct dst_entry, output)=0x70
offsetof(struct dst_entry, __refcnt)=0xb4
offsetof(struct dst_entry, lastuse)=0xc0
offsetof(struct dst_entry, __use)=0xb8
sizeof(struct rtable)=0x140
So we dirty two cache lines instead of one, unless your cpu have 128 bytes cache lines ?
I am quite suprised that my patch to not change lastuse if already set to jiffies changes nothing...
If you have some time, could you also test this (unrelated) patch ?
We can avoid dirty all the time a cache line of loopback device.
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index f2a6e71..0a4186a 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -150,7 +150,10 @@ static int loopback_xmit(struct sk_buff *skb, struct net_device *dev)
return 0;
}
#endif
- dev->last_rx = jiffies;
+#ifdef CONFIG_SMP
+ if (dev->last_rx != jiffies)
+#endif
+ dev->last_rx = jiffies;
/* it's OK to use per_cpu_ptr() because BHs are off */
pcpu_lstats = netdev_priv(dev);
^ permalink raw reply related
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