* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Paul E. McKenney @ 2009-10-24 5:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Octavian Purdila, Benjamin LaHaise, netdev, Cosmin Ratiu
In-Reply-To: <4AE28429.6040608@gmail.com>
On Sat, Oct 24, 2009 at 06:35:53AM +0200, Eric Dumazet wrote:
> Paul E. McKenney a écrit :
> > On Wed, Oct 21, 2009 at 05:40:07PM +0200, Eric Dumazet wrote:
> >> [PATCH] net: allow netdev_wait_allrefs() to run faster
> >>
> >> netdev_wait_allrefs() waits that all references to a device vanishes.
> >>
> >> It currently uses a _very_ pessimistic 250 ms delay between each probe.
> >> Some users report that no more than 4 devices can be dismantled per second,
> >> this is a pretty serious problem for extreme setups.
> >>
> >> Most likely, references only wait for a rcu grace period that should come
> >> fast, so use a schedule_timeout_uninterruptible(1) to allow faster recovery.
> >
> > Is this a place where synchronize_rcu_expedited() is appropriate?
> > (It went in to 2.6.32-rc1.)
>
> Thanks for the tip Paul
>
> I believe netdev_wait_allrefs() is not a perfect candidate, because
> synchronize_sched_expedited() seems really expensive.
It does indeed keep the CPUs quite busy for a bit. ;-)
> Maybe we could call it once only, if we had to call 1 times
> the jiffie delay ?
This could be a very useful approach!
However, please keep in mind that although synchronize_rcu_expedited()
forces a grace period, it does nothing to speed the invocation of other
RCU callbacks. In short, synchronize_rcu_expedited() is a faster version
of synchronize_rcu(), but doesn't necessarily help other synchronize_rcu()
or call_rcu() invocations.
The reason I point this out is that it looks to me that the code below is
waiting for some other task which is in turn waiting on a grace period.
But I don't know this code, so could easily be confused.
Thanx, paul
> diff --git a/net/core/dev.c b/net/core/dev.c
> index fa88dcd..9b04b9a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4970,6 +4970,7 @@ EXPORT_SYMBOL(register_netdev);
> static void netdev_wait_allrefs(struct net_device *dev)
> {
> unsigned long rebroadcast_time, warning_time;
> + unsigned int count = 0;
>
> rebroadcast_time = warning_time = jiffies;
> while (atomic_read(&dev->refcnt) != 0) {
> @@ -4995,7 +4996,10 @@ static void netdev_wait_allrefs(struct net_device *dev)
> rebroadcast_time = jiffies;
> }
>
> - msleep(250);
> + if (count++ == 1)
> + synchronize_rcu_expedited();
> + else
> + schedule_timeout_uninterruptible(1);
>
> if (time_after(jiffies, warning_time + 10 * HZ)) {
> printk(KERN_EMERG "unregister_netdevice: "
>
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Pekka Enberg @ 2009-10-24 6:48 UTC (permalink / raw)
To: Christoph Lameter
Cc: Mel Gorman, Frans Pop, Jiri Kosina, Sven Geggus,
Karol Lewandowski, Tobias Oetiker, Rafael J. Wysocki,
David Miller, Reinette Chatre, Kalle Valo, David Rientjes,
KOSAKI Motohiro, Mohamed Abbas, Jens Axboe, John W. Linville,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
" \" <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, torvalds@l
In-Reply-To: <alpine.DEB.1.10.0910232151380.2001@V090114053VZO-1>
On Thu, 22 Oct 2009, Pekka Enberg wrote:
>> These are pretty obvious bug fixes and should go to linux-next ASAP IMHO.
Christoph Lameter wrote:
> Bug fixes go into main not linux-next. Lets make sure these fixes really
> work and then merge.
Regardless, patches 1-2 and should _really_ go to Linus' tree (and
eventually -stable) while we figure out the rest of the problems. They
fix obvious regressions in the code paths and we have reports from
people that they help. Yes, they don't fix everything for everyone but
we there's no upside in holding back fixes that are simple one line
fixes to regressions.
Pekka
^ permalink raw reply
* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Eric Dumazet @ 2009-10-24 8:49 UTC (permalink / raw)
To: paulmck; +Cc: Octavian Purdila, Benjamin LaHaise, netdev, Cosmin Ratiu
In-Reply-To: <20091024054943.GA6638@linux.vnet.ibm.com>
Paul E. McKenney a écrit :
> On Sat, Oct 24, 2009 at 06:35:53AM +0200, Eric Dumazet wrote:
>
>> Maybe we could call it once only, if we had to call 1 times
>> the jiffie delay ?
>
> This could be a very useful approach!
>
> However, please keep in mind that although synchronize_rcu_expedited()
> forces a grace period, it does nothing to speed the invocation of other
> RCU callbacks. In short, synchronize_rcu_expedited() is a faster version
> of synchronize_rcu(), but doesn't necessarily help other synchronize_rcu()
> or call_rcu() invocations.
>
> The reason I point this out is that it looks to me that the code below is
> waiting for some other task which is in turn waiting on a grace period.
> But I don't know this code, so could easily be confused.
>
Normally, we need a synchronize_rcu() calls, but I feel its bit more than really
needed here.
On my dev machine, a synchronize_rcu() lasts between 2 an 12 ms
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.580259] synchronize_net() 4045596 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.588262] synchronize_net() 7769327 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.625014] synchronize_net() 4772052 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.633008] synchronize_net() 7773896 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.669260] synchronize_net() 3958141 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.677259] synchronize_net() 7755817 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.712011] synchronize_net() 2502544 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.720011] synchronize_net() 7767748 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.754259] synchronize_net() 2087946 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.762258] synchronize_net() 7738054 ns
messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.796011] synchronize_net() 3392760 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.808025] synchronize_net() 11814619 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.848010] synchronize_net() 8970220 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.856015] synchronize_net() 7800782 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.893008] synchronize_net() 6650174 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.897012] synchronize_net() 3744808 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.940202] synchronize_net() 8354366 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.952137] synchronize_net() 11693215 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.985010] synchronize_net() 2355970 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.989009] synchronize_net() 3771419 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.028137] synchronize_net() 7661195 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.036152] synchronize_net() 7800056 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.083135] synchronize_net() 6774026 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.089145] synchronize_net() 5727189 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.130385] synchronize_net() 10133932 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.134399] synchronize_net() 3773058 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.170136] synchronize_net() 4479194 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.178138] synchronize_net() 7710466 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.217198] synchronize_net() 4323437 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.226206] synchronize_net() 8723108 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.268013] synchronize_net() 6221155 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.280007] synchronize_net() 11719297 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.324008] synchronize_net() 11654511 ns
messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.332009] synchronize_net() 7744182 ns
^ permalink raw reply
* Re: [PATCH 00/27] sfc: Cleanup and preparation for new hardware
From: David Miller @ 2009-10-24 11:29 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256322441.2785.3.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 23 Oct 2009 19:27:21 +0100
> This is a mixture of small cleanups, refactoring, renaming and an update
> to the register definitions. There's more to come, in particular
> support for the new hardware, but I'll let you digest this batch first.
All applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH net-next-2.6] xfrm6_tunnel: RCU conversion
From: David Miller @ 2009-10-24 13:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, yoshfuji
In-Reply-To: <4AE28047.1020904@gmail.com>
Nice work Eric, I applied all of your RCU conversions to
net-next-2.6, thanks!
Applying: ipv6 sit: RCU conversion phase I
Applying: ipv6 sit: RCU conversion phase II
Applying: xfrm6_tunnel: RCU conversion
Applying: ipip: convert hash tables locking to RCU
Applying: ip6tnl: convert hash tables locking to RCU
Applying: gre: convert hash tables locking to RCU
^ permalink raw reply
* Re: [RFC] net,socket: introduce build_sockaddr_check helper to catch overflow at build time
From: David Miller @ 2009-10-24 13:12 UTC (permalink / raw)
To: gorcunov; +Cc: netdev
In-Reply-To: <20091023214306.GA30616@lenovo>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Sat, 24 Oct 2009 01:43:06 +0400
> Or say it could be something like that
>
> #define __sockaddr(type, src) \
> ({ build_sockaddr_check(sizeof(type)); (type *) src; })
>
> and say in function af_inet.c:inet_getname instead of
>
> struct sockaddr_in *sin = (struct sockaddr_in *)uaddr;
>
> we may write like
>
> struct sockaddr_in *sin = __sockaddr(struct sockaddr_in, uaddr);
>
> which would check the size.
Or even a "DECLARE_SOCKADDR(type, src, dest)" which encapsulates the
entire declaration statement.
^ permalink raw reply
* Re: [PATCH net-next-2.6] rtnetlink: speedup rtnl_dump_ifinfo()
From: David Miller @ 2009-10-24 13:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, bcrl
In-Reply-To: <4AE06D81.4050003@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 22 Oct 2009 16:34:41 +0200
> When handling large number of netdevice, rtnl_dump_ifinfo()
> is very slow because it has O(N^2) complexity.
>
> Instead of scanning one single list, we can use the 256 sub lists
> of the dev_index hash table.
>
> This considerably speedups "ip link" operations
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] atm: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-24 13:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: roel.kluin, chas, netdev, akpm
In-Reply-To: <4AE1D4FE.5090902@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 23 Oct 2009 18:08:30 +0200
> Roel Kluin a écrit :
>> The variables are unsigned so the `< 0' test always fails, the
>> other part of the test catches wrapped values.
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>> ---
>
> I believe such patches were posted in the past.
>
> General consensus is that compiler is able to do this optimization for us,
> and reader doesnt have to ask to himself : "Is the test safe enough ?"
Conversely, the reader can say "Wow this can be negative? There's
tests missing elsewhere! ... oh, nevermind it's unsigned"
That really wastes people's time too.
I suspect I'll apply these patches. :-)
^ permalink raw reply
* Request: how do packet routing based on input gateway
From: Luca Dionisi @ 2009-10-24 13:22 UTC (permalink / raw)
To: netdev, linux-net
Hi all
I must instruct my server to route packets based on destination prefix
and on the gateway from which the packet arrived.
E.g.
I am 192.168.0.1
a packet for 192.168.1.0/24 which arrived from gateway 192.168.0.2
must go through 192.168.1.1 dev eth0
a packet for 192.168.1.0/24 which arrived from gateway 192.168.0.3
must go through 192.168.1.2 dev eth1
a packet for 192.168.1.0/24 which arrived from any other gateway must
go through 192.168.1.3 dev eth2
The gateway I mean is just the last hop traversed, before me. It's not
necessarily the source of the packet.
How am I supposed to do that?
Regards.
Luca Dionisi
^ permalink raw reply
* Re: Irq architecture for multi-core network driver.
From: David Miller @ 2009-10-24 13:23 UTC (permalink / raw)
To: ddaney; +Cc: cfriesen, netdev, linux-kernel, linux-mips
In-Reply-To: <4AE0DB98.1000101@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Thu, 22 Oct 2009 15:24:24 -0700
> Certainly this is one mode of operation that should be supported, but
> I would also like to be able to go for raw throughput and have as many
> cores as possible reading from a single queue (like I currently have).
You can't do this, at least within the same flow, since as you even
mention in your original posting this can result in packet reordering
which we must avoid as much as is possible.
^ permalink raw reply
* Re: Irq architecture for multi-core network driver.
From: David Miller @ 2009-10-24 13:26 UTC (permalink / raw)
To: ebiederm
Cc: jesse.brandeburg, ddaney, cfriesen, netdev, linux-kernel,
linux-mips
In-Reply-To: <m17huln1ab.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 23 Oct 2009 16:22:36 -0700
> irqbalance is actually more likely to move irqs than the hardware.
> I have heard promises it won't move network irqs but I have seen
> the opposite behavior.
It knows what network devices are named, and looks for those keys
in /proc/interrupts. Anything names 'ethN' will not be moved and
if you name them on a per-queue basis properly (ie. 'ethN-RX1' etc.)
it will flat distribute those interrupts amongst the cpus in the
machine.
So if you're doing "silly stuff" and naming your devices by some other
convention, you would end up defeating the detations built into
irqbalanced.
Actually, let's not even guess, go check out the sources of the
irqbalanced running on your system and make sure it has the network
device logic in it. :-)
^ permalink raw reply
* Re: [PATCH net-next-2.6] xfrm6_tunnel: RCU conversion
From: Eric Dumazet @ 2009-10-24 13:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yoshfuji
In-Reply-To: <20091024.060920.258223911.davem@davemloft.net>
David Miller a écrit :
> Nice work Eric, I applied all of your RCU conversions to
> net-next-2.6, thanks!
>
> Applying: ipv6 sit: RCU conversion phase I
> Applying: ipv6 sit: RCU conversion phase II
> Applying: xfrm6_tunnel: RCU conversion
> Applying: ipip: convert hash tables locking to RCU
> Applying: ip6tnl: convert hash tables locking to RCU
> Applying: gre: convert hash tables locking to RCU
Thanks a lot !
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: David Miller @ 2009-10-24 13:40 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20091023111336.4733.4901.sendpatchset@localhost.localdomain>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Fri, 23 Oct 2009 16:43:36 +0530
> Performance: I ran netperf UDPv6 RR to use connected sockets.
> Tested with a 70 min run, aggregate of 5 netperf runs for
> each result.
Who actually uses connected UDP sockets? :-)
^ permalink raw reply
* iwl3945, after a while stops working with "No space for Tx"
From: Frederik Nosi @ 2009-10-24 13:44 UTC (permalink / raw)
To: Zhu Yi, Reinette Chatre, Intel Linux Wireless, John W. Linville,
Tomas Winkler <tomas.
Cc: netdev, linux-kernel
Hi,
first sorry if somebody is not the right contact, got the adressess from ./scripts/get_maintainer.pl -f drivers/net/wireless/iwlwifi.
>From some kernel versions now, after some time that im using this card it stops working and on messages i get this errors:
Oct 24 14:38:24 kotys NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
[snip pulseaudio's stuppid log spam warning]
Oct 24 14:40:07 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
Oct 24 14:40:09 kotys pulseaudio[16469]: sap.c: sendmsg() failed: Invalid argument
Oct 24 14:40:10 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
Oct 24 14:40:11 kotys kernel: iwl3945 0000:04:00.0: Error sending POWER_TABLE_CMD: time out after 500ms.
Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: set power fail, ret = -110
Oct 24 14:40:14 kotys kernel: No probe response from AP 00:1c:df:82:63:c9 after 500ms, disconnecting.
Oct 24 14:40:14 kotys NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
Oct 24 14:40:14 kotys NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Oct 24 14:40:14 kotys pulseaudio[16469]: sap.c: sendmsg() failed: Invalid argument
Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
Oct 24 14:40:14 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 1)
Oct 24 14:40:15 kotys NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 2)
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 (try 3)
Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
Oct 24 14:40:15 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
Oct 24 14:40:15 kotys kernel: wlan0: direct probe to AP 00:1c:df:82:63:c9 timed out
Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error sending REPLY_RXON: time out after 500ms.
Oct 24 14:40:16 kotys kernel: iwl3945 0000:04:00.0: Error setting new configuration (-110).
When this happens i am able to use the card only after reloading the related modules, iwl3945 ecc. But the problem happens again after some minutes that im connected.
Kernel is 2.6.32-rc5 but his started happening around 2.6.31, not sure exactly what version as i update kernel often. Firmware is iwl3945-ucode-15.32.2.9.
Every other info that you need just ask. I hope i dont have to bisect as this is the laptop i use for work too, but if it's needed i'll do.
I'm not subscribed on any ML, so in case please cc me.
Thanks for all the work!
F.
^ permalink raw reply
* Re: PATCH 23/10]Optimize the upload speed for PPP connection.
From: David Miller @ 2009-10-24 13:46 UTC (permalink / raw)
To: william.allen.simpson; +Cc: huananhu, netdev, linux-kernel, zihan, greg, haegar
In-Reply-To: <4AE19780.3020507@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 23 Oct 2009 07:46:08 -0400
> Concur. I'd go further than that, my code usually made room for at
> least
> a full MTU (MRU) with HDLC escaping. To minimize context switches,
> that
> should be 3014 ((1500 MRU + 2 FCS + 4 header) * 2 escapes + 2 flags).
>
> Even in the old days, when memory was tight, context switches and
> interrupt
> time were more expensive, too. PPP is supposed to scale to OC-192.
Actually I'd like to see ->obuf allocated externally and then
make it simply PAGE_SIZE.
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: Krishna Kumar2 @ 2009-10-24 13:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netdev-owner
In-Reply-To: <20091024.064010.145864194.davem@davemloft.net>
David Miller wrote on 10/24/2009 07:10:10 PM:
>
> > Performance: I ran netperf UDPv6 RR to use connected sockets.
> > Tested with a 70 min run, aggregate of 5 netperf runs for
> > each result.
>
> Who actually uses connected UDP sockets? :-)
Just something I found when running netperf RR tests, and the code is there
doing it anyway. Maybe I can drop doing this testing, but upto you.
Thanks,
- KK
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Mel LKML @ 2009-10-24 13:46 UTC (permalink / raw)
To: Karol Lewandowski
Cc: Mel Gorman, Frans Pop, Jiri Kosina, Sven Geggus, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev, linux-kernel, linux-mm@kvack.org
In-Reply-To: <20091023211239.GA6185@bizet.domek.prywatny>
Hi,
This is the same Mel as mel@csn.ul.ie. The mail server the address is
on has no power until Tuesday so I'm not going to be very unresponsive
until then. Monday is also a public holiday here and apparently they
are upgrading the power transformers near the building.
On 10/23/09, Karol Lewandowski <karol.k.lewandowski@gmail.com> wrote:
> On Fri, Oct 23, 2009 at 06:58:10PM +0200, Karol Lewandowski wrote:
>> On Thu, Oct 22, 2009 at 03:22:31PM +0100, Mel Gorman wrote:
>> > Test 3: If you are getting allocation failures, try with the following
>> > patch
>> >
>> > 3/5 vmscan: Force kswapd to take notice faster when high-order
>> > watermarks are being hit
>
>> No, problem doesn't go away with these patches (1+2+3). However, from
>> my testing this particular patch makes it way, way harder to trigger
>> allocation failures (but these are still present).
>>
>> This bothers me - should I test following patches with or without
>> above patch? This patch makes bug harder to find, IMVHO it doesn't
>> fix the real problem.
> ..
>
>> Test 4: If you are still getting failures, apply the following
>> 4/5 page allocator: Pre-emptively wake kswapd when high-order watermarks
>> are hit
>
> Ok, I've tested patches 1+2+4 and bug, while very hard to trigger, is
> still present. I'll test complete 1-4 patchset as time permits.
>
And also patch 5 please which is the revert. Patch 5 as pointed out is
probably a red herring. Hwoever, it has changed the timing and made a
difference for some testing so I'd like to know if it helps yours as
well.
As things stand, it looks like patches 1+2 should certainly go ahead.
I need to give more thought on patches 3 and 4 as to why they help
Tobias but not anyone elses testing.
Thanks
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCHv2 2.6.32-rc5] r8169: fix Ethernet Hangup for RTL8110SC rev d
From: David Miller @ 2009-10-24 13:48 UTC (permalink / raw)
To: simon.wunderlich; +Cc: netdev, simon.wunderlich, bernhard.schmidt, romieu
In-Reply-To: <20091023065717.GA22484@pandem0nium>
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Date: Fri, 23 Oct 2009 08:57:17 +0200
...
> Signed-off-by: Bernhard Schmidt <bernhard.schmidt@saxnet.de>
> Signed-off-by: Simon Wunderlich <simon.wunderlich@saxnet.de>
> Acked-by: Francois Romieu <romieu@zoreil.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: David Miller @ 2009-10-24 13:49 UTC (permalink / raw)
To: krkumar2; +Cc: netdev, netdev-owner
In-Reply-To: <OF34F531CA.C8E6FDAE-ON65257659.004B6782-65257659.004B99F8@in.ibm.com>
From: Krishna Kumar2 <krkumar2@in.ibm.com>
Date: Sat, 24 Oct 2009 19:15:46 +0530
> David Miller wrote on 10/24/2009 07:10:10 PM:
>>
>> > Performance: I ran netperf UDPv6 RR to use connected sockets.
>> > Tested with a 70 min run, aggregate of 5 netperf runs for
>> > each result.
>>
>> Who actually uses connected UDP sockets? :-)
>
> Just something I found when running netperf RR tests, and the code is there
> doing it anyway. Maybe I can drop doing this testing, but upto you.
Eric Dumazet or someone else made comments recently about how
nobody uses connected UDP sockets.
And if someone actually does, they can complain and we can
go back to looking into it :-)
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Frans Pop @ 2009-10-24 13:51 UTC (permalink / raw)
To: Mel Gorman
Cc: Jiri Kosina, Sven Geggus, Karol Lewandowski, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
In-Reply-To: <1256221356-26049-1-git-send-email-mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
On Thursday 22 October 2009, Mel Gorman wrote:
> Since 2.6.31-rc1, there have been an increasing number of GFP_ATOMIC
> failures. A significant number of these have been high-order GFP_ATOMIC
> failures and while they are generally brushed away, there has been a
> large increase in them recently and there are a number of possible areas
> the problem could be in - core vm, page writeback and a specific driver.
I needed a break and have thus been off-line for a few days. Good to see
there's been progress. I'll try to do some testing tomorrow.
Cheers,
FJP
^ permalink raw reply
* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Paul E. McKenney @ 2009-10-24 13:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Octavian Purdila, Benjamin LaHaise, netdev, Cosmin Ratiu
In-Reply-To: <4AE2BFB3.3060407@gmail.com>
On Sat, Oct 24, 2009 at 10:49:55AM +0200, Eric Dumazet wrote:
> Paul E. McKenney a écrit :
> > On Sat, Oct 24, 2009 at 06:35:53AM +0200, Eric Dumazet wrote:
> >
> >> Maybe we could call it once only, if we had to call 1 times
> >> the jiffie delay ?
> >
> > This could be a very useful approach!
> >
> > However, please keep in mind that although synchronize_rcu_expedited()
> > forces a grace period, it does nothing to speed the invocation of other
> > RCU callbacks. In short, synchronize_rcu_expedited() is a faster version
> > of synchronize_rcu(), but doesn't necessarily help other synchronize_rcu()
> > or call_rcu() invocations.
> >
> > The reason I point this out is that it looks to me that the code below is
> > waiting for some other task which is in turn waiting on a grace period.
> > But I don't know this code, so could easily be confused.
> >
>
> Normally, we need a synchronize_rcu() calls, but I feel its bit more than really
> needed here.
>
> On my dev machine, a synchronize_rcu() lasts between 2 an 12 ms
That sounds like the right range, depending on what else is happening
on the machine at the time.
The synchronize_rcu_expedited() primitive would run in the 10s-100s
of microseconds. It involves a pair of wakeups and a pair of context
switches on each CPU.
Thanx, Paul
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.580259] synchronize_net() 4045596 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.588262] synchronize_net() 7769327 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.625014] synchronize_net() 4772052 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.633008] synchronize_net() 7773896 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.669260] synchronize_net() 3958141 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.677259] synchronize_net() 7755817 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.712011] synchronize_net() 2502544 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.720011] synchronize_net() 7767748 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.754259] synchronize_net() 2087946 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.762258] synchronize_net() 7738054 ns
> messages:Oct 21 19:13:14 svivoipvnx001-00 kernel: [ 2515.796011] synchronize_net() 3392760 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.808025] synchronize_net() 11814619 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.848010] synchronize_net() 8970220 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.856015] synchronize_net() 7800782 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.893008] synchronize_net() 6650174 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.897012] synchronize_net() 3744808 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.940202] synchronize_net() 8354366 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.952137] synchronize_net() 11693215 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.985010] synchronize_net() 2355970 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2515.989009] synchronize_net() 3771419 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.028137] synchronize_net() 7661195 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.036152] synchronize_net() 7800056 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.083135] synchronize_net() 6774026 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.089145] synchronize_net() 5727189 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.130385] synchronize_net() 10133932 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.134399] synchronize_net() 3773058 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.170136] synchronize_net() 4479194 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.178138] synchronize_net() 7710466 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.217198] synchronize_net() 4323437 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.226206] synchronize_net() 8723108 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.268013] synchronize_net() 6221155 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.280007] synchronize_net() 11719297 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.324008] synchronize_net() 11654511 ns
> messages:Oct 21 19:13:15 svivoipvnx001-00 kernel: [ 2516.332009] synchronize_net() 7744182 ns
>
^ permalink raw reply
* Re: DM9000: Fix revision ID for DM9000B
From: David Miller @ 2009-10-24 13:53 UTC (permalink / raw)
To: ben; +Cc: netdev, linux
In-Reply-To: <20091023102631.373421273@fluff.org.uk>
From: Ben Dooks <ben@simtec.co.uk>
Date: Fri, 23 Oct 2009 11:26:31 +0100
> The DM9000B revision ID is 0x1A, not 0x1B as set in the curernt dm9000.h
> header.
>
> Fix bug reported by Paolo Zebelloni.
>
> Signed-off-by: Ben Dooks <ben@simtec.co.uk>
> Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] pktgen: Dont leak kernel memory
From: David Miller @ 2009-10-24 13:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADE95C6.40103@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Oct 2009 07:01:58 +0200
> [PATCH] pktgen: Dont leak kernel memory
>
> While playing with pktgen, I realized IP ID was not filled and a random value
> was taken, possibly leaking 2 bytes of kernel memory.
>
> We can use an increasing ID, this can help diagnostics anyway.
>
> Also clear packet payload, instead of leaking kernel memory.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] Remove bond_dev from xmit_hash_policy call.
From: David Miller @ 2009-10-24 14:00 UTC (permalink / raw)
To: fubar; +Cc: spaans, eric.dumazet, netdev
In-Reply-To: <15659.1256315071@death.nxdomain.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri, 23 Oct 2009 09:24:31 -0700
> Jasper Spaans <spaans@fox-it.com> wrote:
>
>>Now that the bonding device is no longer used in determining the device to
>>which to send packets, it can be dropped from the argument list of the various
>>xmit_hash_policy calls.
>>
>>Signed-off-by: Jasper Spaans <spaans@fox-it.com>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [RFC] [PATCH] udp: Don't save dst in udpv6_sendmsg()
From: Krishna Kumar2 @ 2009-10-24 14:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091024.064915.76607526.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 10/24/2009 07:19:15 PM:
>
> >> Who actually uses connected UDP sockets? :-)
> >
> > Just something I found when running netperf RR tests, and the code is
there
> > doing it anyway. Maybe I can drop doing this testing, but upto you.
>
> Eric Dumazet or someone else made comments recently about how
> nobody uses connected UDP sockets.
>
> And if someone actually does, they can complain and we can
> go back to looking into it :-)
Agreed. Please drop it.
Thanks,
- KK
^ 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