* 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
* Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: David Miller @ 2008-02-18 10:43 UTC (permalink / raw)
To: devik; +Cc: linux-kernel, kaber, netdev
In-Reply-To: <47B95909.8060202@cdi.cz>
From: Martin Devera <devik@cdi.cz>
Date: Mon, 18 Feb 2008 11:08:09 +0100
> 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 ?
Sure.
^ permalink raw reply
* [PATCH][IBMVETH]: Use single_open instead of manual manipulations.
From: Pavel Emelyanov @ 2008-02-18 10:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Netdev List, Brian King
The code opening proc entry for each device makes the
same thing, as the single_open does, so remove the
unneeded code.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
index 57772be..bb31e09 100644
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -1259,26 +1259,7 @@ static void ibmveth_proc_unregister_driver(void)
remove_proc_entry(IBMVETH_PROC_DIR, init_net.proc_net);
}
-static void *ibmveth_seq_start(struct seq_file *seq, loff_t *pos)
-{
- if (*pos == 0) {
- return (void *)1;
- } else {
- return NULL;
- }
-}
-
-static void *ibmveth_seq_next(struct seq_file *seq, void *v, loff_t *pos)
-{
- ++*pos;
- return NULL;
-}
-
-static void ibmveth_seq_stop(struct seq_file *seq, void *v)
-{
-}
-
-static int ibmveth_seq_show(struct seq_file *seq, void *v)
+static int ibmveth_show(struct seq_file *seq, void *v)
{
struct ibmveth_adapter *adapter = seq->private;
char *current_mac = ((char*) &adapter->netdev->dev_addr);
@@ -1302,27 +1283,10 @@ static int ibmveth_seq_show(struct seq_file *seq, void *v)
return 0;
}
-static struct seq_operations ibmveth_seq_ops = {
- .start = ibmveth_seq_start,
- .next = ibmveth_seq_next,
- .stop = ibmveth_seq_stop,
- .show = ibmveth_seq_show,
-};
static int ibmveth_proc_open(struct inode *inode, struct file *file)
{
- struct seq_file *seq;
- struct proc_dir_entry *proc;
- int rc;
-
- rc = seq_open(file, &ibmveth_seq_ops);
- if (!rc) {
- /* recover the pointer buried in proc_dir_entry data */
- seq = file->private_data;
- proc = PDE(inode);
- seq->private = proc->data;
- }
- return rc;
+ return single_open(file, ibmveth_show, PDE(inode)->data);
}
static const struct file_operations ibmveth_proc_fops = {
@@ -1330,7 +1294,7 @@ static const struct file_operations ibmveth_proc_fops = {
.open = ibmveth_proc_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = single_release,
};
static void ibmveth_proc_register_adapter(struct ibmveth_adapter *adapter)
^ permalink raw reply related
* [PATCH][IPV6]: Use BUG_ON instead of if + BUG in fib6_del_route.
From: Pavel Emelyanov @ 2008-02-18 12:50 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index f93407c..bab72b6 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1151,7 +1151,7 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
fn = fn->parent;
}
/* No more references are possible at this point. */
- if (atomic_read(&rt->rt6i_ref) != 1) BUG();
+ BUG_ON(atomic_read(&rt->rt6i_ref) != 1);
}
inet6_rt_notify(RTM_DELROUTE, rt, info);
^ permalink raw reply related
* Re: [2.6.25-rc2, 2.6.24-rc8] page allocation failure...
From: Andrew Morton @ 2008-02-18 12:58 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: Linux Kernel, netdev, Auke Kok
In-Reply-To: <6278d2220802170520k2ddf9072x386e4a9e3062f4da@mail.gmail.com>
On Sun, 17 Feb 2008 13:20:59 +0000 "Daniel J Blueman" <daniel.blueman@gmail.com> wrote:
> I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again.
>
> It's clearly non-fatal, but then do we expect it to occur?
>
> Daniel
>
> --- [dmesg]
>
> [ 1250.822786] swapper: page allocation failure. order:3, mode:0x4020
> [ 1250.822786] Pid: 0, comm: swapper Not tainted 2.6.25-rc2-119 #2
> [ 1250.822786]
> [ 1250.822786] Call Trace:
> [ 1250.822786] <IRQ> [<ffffffff8025fe9e>] __alloc_pages+0x34e/0x3a0
> [ 1250.822786] [<ffffffff8048c6df>] ? __netdev_alloc_skb+0x1f/0x40
> [ 1250.822786] [<ffffffff8027acc2>] __slab_alloc+0x102/0x3d0
> [ 1250.822786] [<ffffffff8048c6df>] ? __netdev_alloc_skb+0x1f/0x40
> [ 1250.822786] [<ffffffff8027b8cb>] __kmalloc_track_caller+0x7b/0xc0
> [ 1250.822786] [<ffffffff8048b74f>] __alloc_skb+0x6f/0x160
> [ 1250.822786] [<ffffffff8048c6df>] __netdev_alloc_skb+0x1f/0x40
> [ 1250.822786] [<ffffffff8042652d>] e1000_alloc_rx_buffers+0x1ed/0x260
> [ 1250.822786] [<ffffffff80426b5a>] e1000_clean_rx_irq+0x22a/0x330
> [ 1250.822786] [<ffffffff80422981>] e1000_clean+0x1e1/0x540
> [ 1250.822786] [<ffffffff8024b7a5>] ? tick_program_event+0x45/0x70
> [ 1250.822786] [<ffffffff804930ba>] net_rx_action+0x9a/0x150
> [ 1250.822786] [<ffffffff802336b4>] __do_softirq+0x74/0xf0
> [ 1250.822786] [<ffffffff8020c5fc>] call_softirq+0x1c/0x30
> [ 1250.822786] [<ffffffff8020eaad>] do_softirq+0x3d/0x80
> [ 1250.822786] [<ffffffff80233635>] irq_exit+0x85/0x90
> [ 1250.822786] [<ffffffff8020eba5>] do_IRQ+0x85/0x100
> [ 1250.822786] [<ffffffff8020a5b0>] ? mwait_idle+0x0/0x50
> [ 1250.822786] [<ffffffff8020b981>] ret_from_intr+0x0/0xa
> [ 1250.822786] <EOI> [<ffffffff8020a5f5>] ? mwait_idle+0x45/0x50
> [ 1250.822786] [<ffffffff80209a92>] ? enter_idle+0x22/0x30
> [ 1250.822786] [<ffffffff8020a534>] ? cpu_idle+0x74/0xa0
> [ 1250.822786] [<ffffffff80527825>] ? rest_init+0x55/0x60
They're regularly reported with e1000 too - I don't think aything really
changed.
e1000 has this crazy problem where because of a cascade of follies (mainly
borked hardware) it has to do a 32kb allocation for a 9kb(?) packet. It
would be sad if that was carried over into e1000e?
^ permalink raw reply
* Re: [2.6.25-rc2] e100: Trying to free already-free IRQ 11 during suspend ...
From: Andrew Morton @ 2008-02-18 13:01 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: e1000-devel, netdev, linux-kernel
In-Reply-To: <200802171536.51695.arvidjaar@mail.ru>
On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>
> [ 8803.850634] ACPI: Preparing to enter system sleep state S3
> [ 8803.853141] Suspending console(s)
> [ 8805.287505] serial 00:09: disabled
> [ 8805.291564] Trying to free already-free IRQ 11
> [ 8805.291579] Pid: 6920, comm: pm-suspend Not tainted 2.6.25-rc2-1avb #2
> [ 8805.291628] [<c0152127>] free_irq+0xb7/0x130
> [ 8805.291675] [<c024bd80>] e100_suspend+0xc0/0x100
> [ 8805.291724] [<c01eaa36>] pci_device_suspend+0x26/0x70
> [ 8805.291747] [<c0243674>] suspend_device+0x94/0xd0
> [ 8805.291763] [<c02439a3>] device_suspend+0x153/0x240
> [ 8805.291784] [<c014314f>] suspend_devices_and_enter+0x4f/0xf0
> [ 8805.291808] [<c0143a5f>] ? freeze_processes+0x3f/0x80
> [ 8805.291825] [<c01432fa>] enter_state+0xaa/0x140
> [ 8805.291840] [<c014341f>] state_store+0x8f/0xd0
> [ 8805.291852] [<c0143390>] ? state_store+0x0/0xd0
> [ 8805.291866] [<c01d3404>] kobj_attr_store+0x24/0x30
> [ 8805.291901] [<c01b547b>] sysfs_write_file+0xbb/0x110
> [ 8805.291936] [<c0177d79>] vfs_write+0x99/0x130
> [ 8805.291963] [<c01b53c0>] ? sysfs_write_file+0x0/0x110
> [ 8805.291979] [<c01782fd>] sys_write+0x3d/0x70
> [ 8805.291998] [<c010409a>] sysenter_past_esp+0x5f/0xa5
> [ 8805.292038] =======================
> [ 8805.347640] ACPI: PCI interrupt for device 0000:00:06.0 disabled
> [ 8805.361128] ACPI: PCI interrupt for device 0000:00:02.0 disabled
> [ 8805.376670] hwsleep-0322 [00] enter_sleep_state : Entering sleep state [S3]
> [ 8805.376670] Back to C!
>
> Interface is unused normally (only for netconsole sometimes). dmesg and config
> attached.
Does reverting this:
commit 8543da6672b0994921f014f2250e27ae81645580
Author: Auke Kok <auke-jan.h.kok@intel.com>
Date: Wed Dec 12 16:30:42 2007 -0800
e100: free IRQ to remove warningwhenrebooting
with this patch:
--- a/drivers/net/e100.c~revert-1
+++ a/drivers/net/e100.c
@@ -2804,9 +2804,8 @@ static int e100_suspend(struct pci_dev *
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- free_irq(pdev->irq, netdev);
-
pci_disable_device(pdev);
+ free_irq(pdev->irq, netdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
@@ -2848,8 +2847,6 @@ static void e100_shutdown(struct pci_dev
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- free_irq(pdev->irq, netdev);
-
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
}
_
fix it?
> Hmm ... after resume device has disappeared at all ...
>
> {pts/1}% cat /proc/interrupts
> CPU0
> 0: 1290492 XT-PIC-XT timer
> 1: 6675 XT-PIC-XT i8042
> 2: 0 XT-PIC-XT cascade
> 3: 2 XT-PIC-XT
> 4: 2 XT-PIC-XT
> 5: 3 XT-PIC-XT
> 7: 4 XT-PIC-XT irda0
> 8: 0 XT-PIC-XT rtc0
> 9: 583 XT-PIC-XT acpi
> 10: 2 XT-PIC-XT
> 11: 31483 XT-PIC-XT yenta, yenta, yenta, ohci_hcd:usb1, ALI 5451, pcmcia0.0
> 12: 28070 XT-PIC-XT i8042
> 14: 21705 XT-PIC-XT ide0
> 15: 82123 XT-PIC-XT ide1
> NMI: 0 Non-maskable interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
I hope that's not a separate bug...
-------------------------------------------------------------------------
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: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Andrew Morton @ 2008-02-18 13:00 UTC (permalink / raw)
To: Chris Rankin; +Cc: linux-acpi, linux-kernel, netdev, Stephen Hemminger
In-Reply-To: <23590.97305.qm@web52910.mail.re2.yahoo.com>
On Sun, 17 Feb 2008 00:54:08 +0000 (GMT) Chris Rankin <rankincj@yahoo.com> wrote:
> [Try this again, except this time I'll force the attachment as inline text!]
>
> Hi,
>
> I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, by using the
> "acpi=noirq" option. (There does seem to be some unhappiness with bridge symlinks in sysfs,
> though.)
>
> ...
>
> sysfs: duplicate filename 'bridge' can not be created
> WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> [<c0105990>] show_trace+0x12/0x14
> [<c010613d>] dump_stack+0x6c/0x72
> [<c01991bf>] sysfs_add_one+0x57/0xbc
> [<c0199e41>] sysfs_create_link+0xc2/0x10d
> [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> [<c034016c>] pci_legacy_init+0x56/0xe3
> [<c03274e1>] kernel_init+0x157/0x2c3
> [<c0104c83>] kernel_thread_helper+0x7/0x10
> =======================
> pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> sysfs: duplicate filename 'bridge' can not be created
> WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> [<c0105990>] show_trace+0x12/0x14
> [<c010613d>] dump_stack+0x6c/0x72
> [<c01991bf>] sysfs_add_one+0x57/0xbc
> [<c0199e41>] sysfs_create_link+0xc2/0x10d
> [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> [<c034016c>] pci_legacy_init+0x56/0xe3
> [<c03274e1>] kernel_init+0x157/0x2c3
> [<c0104c83>] kernel_thread_helper+0x7/0x10
> =======================
I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
^ permalink raw reply
* Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Chris Rankin @ 2008-02-18 13:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-acpi, linux-kernel, netdev, Stephen Hemminger
In-Reply-To: <20080218050049.12bcc596.akpm@linux-foundation.org>
--- Andrew Morton <akpm@linux-foundation.org> wrote:
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
> > pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
>
> I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
Obviously not in 2.6.24.1, and I thought that 2.6.24.2 just added the fix for the vmsplice
exploit. So unless 2.6.24.3 has been released...?
Cheers,
Chris
___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
^ permalink raw reply
* [patch 0/1] s390: claw - More use DIV_ROUND_UP
From: Ursula Braun @ 2008-02-18 13:41 UTC (permalink / raw)
To: jgarzik, netdev, linux-s390, julia
--
Jeff,
this patch is intended for 2.6.25.
It makes use of the DIV_ROUND_UP function as proposed by Julia Lawall.
Regards, Ursula Braun
^ permalink raw reply
* [patch 1/1] claw: make use of DIV_ROUND_UP
From: Ursula Braun @ 2008-02-18 13:41 UTC (permalink / raw)
To: jgarzik, netdev, linux-s390, julia
In-Reply-To: <20080218134154.893427000@linux.vnet.ibm.com>
[-- Attachment #1: 715-claw-div.diff --]
[-- Type: text/plain, Size: 3391 bytes --]
From: Julia Lawall <julia@diku.dk>
The kernel.h macro DIV_ROUND_UP performs the computation
(((n) + (d) - 1) / (d)) but is perhaps more readable.
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
drivers/s390/net/claw.c | 39 ++++++++++++++++++---------------------
1 file changed, 18 insertions(+), 21 deletions(-)
Index: linux-2.6-uschi/drivers/s390/net/claw.c
===================================================================
--- linux-2.6-uschi.orig/drivers/s390/net/claw.c
+++ linux-2.6-uschi/drivers/s390/net/claw.c
@@ -1851,8 +1851,7 @@ claw_hw_tx(struct sk_buff *skb, struct n
}
}
/* See how many write buffers are required to hold this data */
- numBuffers= ( skb->len + privptr->p_env->write_size - 1) /
- ( privptr->p_env->write_size);
+ numBuffers = DIV_ROUND_UP(skb->len, privptr->p_env->write_size);
/* If that number of buffers isn't available, give up for now */
if (privptr->write_free_count < numBuffers ||
@@ -2114,8 +2113,7 @@ init_ccw_bk(struct net_device *dev)
*/
ccw_blocks_perpage= PAGE_SIZE / CCWBK_SIZE;
ccw_pages_required=
- (ccw_blocks_required+ccw_blocks_perpage -1) /
- ccw_blocks_perpage;
+ DIV_ROUND_UP(ccw_blocks_required, ccw_blocks_perpage);
#ifdef DEBUGMSG
printk(KERN_INFO "%s: %s() > ccw_blocks_perpage=%d\n",
@@ -2131,30 +2129,29 @@ init_ccw_bk(struct net_device *dev)
* provide good performance. With packing buffers support 32k
* buffers are used.
*/
- if (privptr->p_env->read_size < PAGE_SIZE) {
- claw_reads_perpage= PAGE_SIZE / privptr->p_env->read_size;
- claw_read_pages= (privptr->p_env->read_buffers +
- claw_reads_perpage -1) / claw_reads_perpage;
+ if (privptr->p_env->read_size < PAGE_SIZE) {
+ claw_reads_perpage = PAGE_SIZE / privptr->p_env->read_size;
+ claw_read_pages = DIV_ROUND_UP(privptr->p_env->read_buffers,
+ claw_reads_perpage);
}
else { /* > or equal */
- privptr->p_buff_pages_perread=
- (privptr->p_env->read_size + PAGE_SIZE - 1) / PAGE_SIZE;
- claw_read_pages=
- privptr->p_env->read_buffers * privptr->p_buff_pages_perread;
+ privptr->p_buff_pages_perread =
+ DIV_ROUND_UP(privptr->p_env->read_size, PAGE_SIZE);
+ claw_read_pages = privptr->p_env->read_buffers *
+ privptr->p_buff_pages_perread;
}
if (privptr->p_env->write_size < PAGE_SIZE) {
- claw_writes_perpage=
- PAGE_SIZE / privptr->p_env->write_size;
- claw_write_pages=
- (privptr->p_env->write_buffers + claw_writes_perpage -1) /
- claw_writes_perpage;
+ claw_writes_perpage =
+ PAGE_SIZE / privptr->p_env->write_size;
+ claw_write_pages = DIV_ROUND_UP(privptr->p_env->write_buffers,
+ claw_writes_perpage);
}
else { /* > or equal */
- privptr->p_buff_pages_perwrite=
- (privptr->p_env->read_size + PAGE_SIZE - 1) / PAGE_SIZE;
- claw_write_pages=
- privptr->p_env->write_buffers * privptr->p_buff_pages_perwrite;
+ privptr->p_buff_pages_perwrite =
+ DIV_ROUND_UP(privptr->p_env->read_size, PAGE_SIZE);
+ claw_write_pages = privptr->p_env->write_buffers *
+ privptr->p_buff_pages_perwrite;
}
#ifdef DEBUGMSG
if (privptr->p_env->read_size < PAGE_SIZE) {
--
^ permalink raw reply
* ipv6 debugging
From: Ferenc Wagner @ 2008-02-18 14:06 UTC (permalink / raw)
To: netdev
Hi,
I'm kindly asking for some debugging tips with the following problem:
a machine is running Linux 2.6.24.2, several 802.1q VLAN-s over
active/backup bonding over two physical interfaces. Everything is
allright, except for after a reboot, there's no IPv6, while IPv4
works. The router's ARP(6) table is empty, the machine doesn't answer
ping6. However, if I start tcpdump -i bond0 ip6, everything is
allright again. There are some indications that after some period
without IPv6 traffic, the same can happen again. Are there known
issues which can exhibit themselves like this? Other very similar
setups don't show this erratic behaviour.
I know that the above doesn't give a fully detailed picture, but
thought that I'd better ask before taking the setup into pieces.
--
Thanks for your thoughts,
Feri.
^ permalink raw reply
* Re: [PATCH 2.6.24-mm1] error compiling net driver NE2000/NE1000
From: Pierre Peiffer @ 2008-02-18 15:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, Alan Cox
In-Reply-To: <20080204131038.699c28c1.akpm@linux-foundation.org>
Hi,
I don't know if I have to warn on this or not, but as I didn't find any
discussion, it's probably better to mention it: the compiling error reported
below (or here: http://lkml.org/lkml/2008/2/4/173 ) does not seem to be
corrected in 2.6.25-rc2.mm1... So, I don't know if a fix is going on somewhere
or if the bug has fallen in a black hole.
(In the original mail, I've proposed a patch as a quick fix, but I don't know if
it can be considered as a definitive correction or not)
Thanks,
P.
Andrew Morton wrote:
> On Mon, 4 Feb 2008 16:29:21 +0100
> Pierre Peiffer <pierre.peiffer@bull.net> wrote:
>
>> Hi,
>>
>> When I compile the kernel 2.6.24-mm1 with:
>> CONFIG_NET_ISA=y
>> CONFIG_NE2000=y
>>
>> I have the following compile error:
>> ...
>> GEN .version
>> CHK include/linux/compile.h
>> UPD include/linux/compile.h
>> CC init/version.o
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> drivers/built-in.o: In function `ne_block_output':
>> linux-2.6.24-mm1/drivers/net/ne.c:797: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_drv_resume':
>> linux-2.6.24-mm1/drivers/net/ne.c:858: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_probe1':
>> linux-2.6.24-mm1/drivers/net/ne.c:539: undefined reference to `NS8390_init'
>> make[1]: *** [.tmp_vmlinux1] Error 1
>> make: *** [sub-make] Error 2
>
> Thanks for reporting this.
>
>> As I saw that the file 8390p.c is compiled for this driver, but not the file
>> 8390.c which contains this function NS8390_init(), I fixed this error with
>> the following patch.
>
> Alan's
> 8390-split-8390-support-into-a-pausing-and-a-non-pausing-driver-core.patch
> would be a prime suspect. I assume this bug isn't present ing mainline or
> in 2.6.24?
>
>> As NS8390p_init() does the same thing than NS8390_init(), I suppose that this is the right fix ?
>>
>> Signed-off-by: Pierre Peiffer <pierre.peiffer@bull.net>
>> ---
>> drivers/net/ne.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> Index: b/drivers/net/ne.c
>> ===================================================================
>> --- a/drivers/net/ne.c
>> +++ b/drivers/net/ne.c
>> @@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_d
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> dev->poll_controller = eip_poll;
>> #endif
>> - NS8390_init(dev, 0);
>> + NS8390p_init(dev, 0);
>>
>> ret = register_netdev(dev);
>> if (ret)
>> @@ -794,7 +794,7 @@ retry:
>> if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
>> printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
>> ne_reset_8390(dev);
>> - NS8390_init(dev,1);
>> + NS8390p_init(dev,1);
>> break;
>> }
>>
>> @@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform
>>
>> if (netif_running(dev)) {
>> ne_reset_8390(dev);
>> - NS8390_init(dev, 1);
>> + NS8390p_init(dev, 1);
>> netif_device_attach(dev);
>> }
>> return 0;
>
>
>
>
--
Pierre Peiffer
^ 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