Message ID | 1307410786-19110-3-git-send-email-lucian.grijincu@gmail.com |
---|---|
State | Rejected, archived |
Delegated to: | David Miller |
Headers | show |
Le mardi 07 juin 2011 à 04:39 +0300, Lucian Adrian Grijincu a écrit : > The most like case is that no one else is registering devices with a > name like "dummy%d". > > We can bring the complexity down by replacing: > - alloc_netdev_id which is O(N) with > - alloc_netdev_id which, on the average case, is O(1). > > $ time modprobe dummy numdummies=5000 > - with alloc_netdev : 9.50s > - with alloc_netdev_id: 3.50s > > NOTE: Stats generated on a heavily patched 3.0-rc1 which replaces the > current O(N^2) sysctl algorithm with a better one. Yes, and disabled hotplug I guess. Dont try this on a random computer ;) # time modprobe dummy numdummies=5000 real 4m45.646s user 0m0.000s sys 0m12.440s # uptime 05:13:46 up 13:30, 3 users, load average: 11221.41, 6918.70, 3101.12 # uptime 05:18:45 up 13:35, 3 users, load average: 12159.82, 10277.39, 5623.19 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Tue, 07 Jun 2011 05:19:25 +0200 > Le mardi 07 juin 2011 à 04:39 +0300, Lucian Adrian Grijincu a écrit : >> The most like case is that no one else is registering devices with a >> name like "dummy%d". >> >> We can bring the complexity down by replacing: >> - alloc_netdev_id which is O(N) with >> - alloc_netdev_id which, on the average case, is O(1). >> >> $ time modprobe dummy numdummies=5000 >> - with alloc_netdev : 9.50s >> - with alloc_netdev_id: 3.50s >> >> NOTE: Stats generated on a heavily patched 3.0-rc1 which replaces the >> current O(N^2) sysctl algorithm with a better one. > > Yes, and disabled hotplug I guess. > > Dont try this on a random computer ;) > > # time modprobe dummy numdummies=5000 > > real 4m45.646s > user 0m0.000s > sys 0m12.440s > # uptime > 05:13:46 up 13:30, 3 users, load average: 11221.41, 6918.70, 3101.12 ROFL -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 7, 2011 at 6:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le mardi 07 juin 2011 à 04:39 +0300, Lucian Adrian Grijincu a écrit : >> The most like case is that no one else is registering devices with a >> name like "dummy%d". >> >> We can bring the complexity down by replacing: >> - alloc_netdev_id which is O(N) with >> - alloc_netdev_id which, on the average case, is O(1). >> >> $ time modprobe dummy numdummies=5000 >> - with alloc_netdev : 9.50s >> - with alloc_netdev_id: 3.50s >> >> NOTE: Stats generated on a heavily patched 3.0-rc1 which replaces the >> current O(N^2) sysctl algorithm with a better one. > > Yes, and disabled hotplug I guess. $ cat .config | grep HOTPLUG CONFIG_HOTPLUG=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ACPI_HOTPLUG_CPU=y # CONFIG_HOTPLUG_PCI is not set I would guess you're going for CONFIG_HOTPLUG_PCI or CONFIG_HOTPLUG_CPU, but I don't understand the implications. > Dont try this on a random computer ;) Could you briefly explain what's at stake here? What can go wrong if we do this? I wasn't advocating replacing all alloc_netdev calls with the new call. > # time modprobe dummy numdummies=5000 > > real 4m45.646s > user 0m0.000s > sys 0m12.440s > # uptime > 05:13:46 up 13:30, 3 users, load average: 11221.41, 6918.70, 3101.12 > # uptime > 05:18:45 up 13:35, 3 users, load average: 12159.82, 10277.39, 5623.19 I don't get where you're going with these stats. I don't care much about these patches, and even less if they're fundamentally borked, but I'd like to know how/why they're not ok. Please spare a second and illuminate me; I feel left out on a big joke.
Le mardi 07 juin 2011 à 10:49 +0300, Lucian Adrian Grijincu a écrit : > On Tue, Jun 7, 2011 at 6:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > > Le mardi 07 juin 2011 à 04:39 +0300, Lucian Adrian Grijincu a écrit : > >> The most like case is that no one else is registering devices with a > >> name like "dummy%d". > >> > >> We can bring the complexity down by replacing: > >> - alloc_netdev_id which is O(N) with > >> - alloc_netdev_id which, on the average case, is O(1). > >> > >> $ time modprobe dummy numdummies=5000 > >> - with alloc_netdev : 9.50s > >> - with alloc_netdev_id: 3.50s > >> > >> NOTE: Stats generated on a heavily patched 3.0-rc1 which replaces the > >> current O(N^2) sysctl algorithm with a better one. > > > > Yes, and disabled hotplug I guess. > > Some distros have : $ cat /proc/sys/kernel/hotplug /sbin/hotplug http://linux.die.net/man/8/hotplug Basically this starts a lot of process when a new device is created. modprobe dummy numdummies=5000 This previous line ask 5000 asynchronous hotplug start, so it launches thousands of processes, all fighting to get RTNL because they access network configuration data. Please note I was not commenting your patch (it seems fine at a first glance), only warning people not doing "modprobe dummy numdummies=5000" without thinking a bit if their machine wont crash or freeze :) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 7, 2011 at 10:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Please note I was not commenting your patch (it seems fine at a first > glance), only warning people not doing "modprobe dummy numdummies=5000" > without thinking a bit if their machine wont crash or freeze :) Sorry for fooling you into killing your machine. :)) Later today I'll post a scheduler patch that speeds up the fork bomb too :) Thank you for the explanation. @David: I see [1][2] that you marked the patches as Rejected. If it's not a script that sends all my patches to /dev/null because of the 100+ patch set I sent a while back, could you tell me why you rejected the patches? Something fundamentally wrong with them, optimisations that "normal people" don't care about, etc.? [1] http://patchwork.ozlabs.org/patch/99065/ [2] http://patchwork.ozlabs.org/patch/99066/
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com> Date: Tue, 7 Jun 2011 11:30:38 +0300 > @David: I see [1][2] that you marked the patches as Rejected. If it's > not a script that sends all my patches to /dev/null because of the > 100+ patch set I sent a while back, could you tell me why you rejected > the patches? I misfired while changing patch states earlier today, I put them back into "Under Review" -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Miller <davem@davemloft.net> Date: Tue, 07 Jun 2011 02:29:26 -0700 (PDT) > From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com> > Date: Tue, 7 Jun 2011 11:30:38 +0300 > >> @David: I see [1][2] that you marked the patches as Rejected. If it's >> not a script that sends all my patches to /dev/null because of the >> 100+ patch set I sent a while back, could you tell me why you rejected >> the patches? > > I misfired while changing patch states earlier today, I put them back > into "Under Review" So I took a look again, you're patches introduce problems. We don't do the instance allocation and (more importantly) conflict validation of the netdev name in alloc_netdev_mqs(), we do it when the netdev is registered. So with your patch some other entity could rename a random netdev to "dummy62" in between the alloc_netdev_id() call and the register and the register will fail erroneously. I really don't like this optimization, sorry. Make dev_alloc_name() less stupid instead. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c index 39cf9b9..24d4ee5 100644 --- a/drivers/net/dummy.c +++ b/drivers/net/dummy.c @@ -159,12 +159,14 @@ static struct rtnl_link_ops dummy_link_ops __read_mostly = { module_param(numdummies, int, 0); MODULE_PARM_DESC(numdummies, "Number of dummy pseudo devices"); + +static int last_device_id = -1; static int __init dummy_init_one(void) { struct net_device *dev_dummy; int err; - dev_dummy = alloc_netdev(0, "dummy%d", dummy_setup); + dev_dummy = alloc_netdev_id(0, "dummy%d", dummy_setup, &last_device_id); if (!dev_dummy) return -ENOMEM;
The most like case is that no one else is registering devices with a name like "dummy%d". We can bring the complexity down by replacing: - alloc_netdev_id which is O(N) with - alloc_netdev_id which, on the average case, is O(1). $ time modprobe dummy numdummies=5000 - with alloc_netdev : 9.50s - with alloc_netdev_id: 3.50s NOTE: Stats generated on a heavily patched 3.0-rc1 which replaces the current O(N^2) sysctl algorithm with a better one. Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com> --- drivers/net/dummy.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)