Slow device creation + procfs overflows
Mike Ireton <[email protected]> Sat, 27 Jan 2007 22:37:45 -0800
| Newsgroups | gmane.linux.drivers.vlan |
|---|---|
| Message-ID | <[email protected]> |
Howdy,
I've noted two problems which I am not sure weather or not are 8021q
specfic, but google doesn't seem to have any similar mailing list
posting documenting these issues.
I have a simple script which creates 2000 vlan devices and, damm, it
runs slow! Device creation can be as slow as 2 devices per second and
there are very noticable pauses during execution. I have noted also
that if I access certain /proc files during this time, device creation
halts completely. The speed of device creation does not appear related
to the number done or index - indeed, the first 20 devices are just as
slow as the last 20. I suppose it's not too awfully important and
doesn't really have much overall impact because device creation is such
an infrequent event even on a very busy network server such as dedicated
pppoe box. I just thought I'd bring it up for comment.
Secondly, under linux 2.4.27 (but not under 2.6.8 that I can see),
there appears to be a maximum number of devices that can be registered
before I start getting kernel errors for "VLAN: failed to add proc entry
for xxxx". My test script creates the devices in a loop and sets an ip
address as each comes up, and seems to get 108 devices created before
the errors start appearing. If I omit the 'ifconfig', then there doesn't
seem to be any problem and I can create all 2000 devices. Under kernel
2.6.8, I can run the same test script with ifconfig the new interfaces
and no problem appears. I have also noted that under 2.4.32, the issue
also appears to affect listing of ppp interfaces in
/proc/sys/net/ipv4/conf/ where if I have 450 or so actual pppd's
running, this directory only lists about 119 interfaces total. This
sounds like a procfs limitation (in 2.4) but I'm not that familliar with
the different peices to know for sure.
Comments?
Mike-
I realise the speed of device creation is probbly not too important
and probbly involves device structure locking issues that we don't want
to visit. Th