HI Richard, hi list.
I will reformat these (as well as the new drivers), clean them up to the current coding standard and resubmit so it will be easier to review them and consider form merging.
Apology for not coming back to this earlier - I was busy with the qemu counterparts of the transport patches (I will also apply the "lessons learned" from there to these).
On 28/02/14 08:54, Anton Ivanov (antivano) wrote:
I need to pull actual changesets for the drivers, etc properly and
verify that they build so those will be coming next week. You will be
getting them one by one.
1. Memory corruption.
The reverse case of this race (you need to msync, before you do non-mmap
fileops) is well known and textbook. This is the first and only time I
have seen this one (fsync before mmap). I have not heard it mentioned
either. It is however fairly easy to reproduce. If you run 200+ UML on a
system ~0.2-0.5% will always die at startup with a memory corruption
warning. While this does not happen every time (0.2-0.5% and only on
startup) it is very reproducible for systems running lots of UMLs.
Once this fix went in we stopped seeing that one. Observed on 3.2, 3.3
and 3.8, fix tested on 3.2, 3.3, 3.4 and 3.8.
Linux actually produces SIGPIPE ane EPIPE not only on missing reader. It
will produce it under some circumstances on a stalled reader. Discovered
when running UML under expect and/or trying to use fds and other virtual
serials to do management transactions.
While I have not seen it on UML internal pipes I would not be surprised
if you can reproduce it there too (f.e. if ubd thread is too slow). So
SIGPIPE needs to be disabled. From there on, for most drivers have
correct error handling for this.
Observed on 3.2, 3.3 and 3.8, fix tested on 3.2, 3.3, 3.4 and 3.8.
On 28/02/14 08:33, Richard Weinberger wrote:
Am 28.02.2014 09:27, schrieb Anton Ivanov (antivano):
Hi Richard, Hi Jeff, hi list,
On behalf of Cisco systems, I am authorized to make a offer a set bug
fixes as well as contribute several additional features and performance
improvements to UML. All of these have been used internally for a couple
of years and will ship as parts of product(s) in the near future. Some
of these improve performance by up to 8 times on use cases which are of
interest to us and are likely to be of interest to the community.
As the full patchset is now in the 100k+ zone, so I am going to do only
the announcement now and submit the patches one by one after that over
the next 1-2 weeks.
We will submit separately bug fixes for:
1. Critical memory corruption on startup observed on heavily loaded
machines (especially when multiple UMLs run simultaneously).
2. Fix(es) for incorrect handling of error conditions when UML is run
under expect and conX=fd: is used to communicate with another process.
The same error may be observed on internal UML IPCs too leading to
I will also file bugs for both vs Debian UML package so that patches for
both can go in ASAP.
In addition to the bug fixes, the new features include:
1. Several transports. All can do up to multi-gigabit throughput on some
scenarios. We are contributing their counterparts to qemu/kvm as well.
1.1. Direct connection of UML to overlay networks/L2 VPNs using L2TPv3.
This has a number of advantages compared to the existing UML "multicast"
and qemu "socket" transports.
* Standard compliant - RFC 3931 updated recently by RFC 5641
* Supported on most network equipment
* Allowing to move virtual switching off-host to an NPU or high
performance physical switch
* Allowing to mix virtual and physical switching (well supported on
modern Linuxes and other OSes)
* Well researched security profile as well as established
interactions with IPSEC allowing to extend virtual networks outside the
datacenter to remote physical devices and/or VMs.
1.2. Raw transport which allows both bi-directional communication with
any network device which looks like Ethernet as well as in-span
listening at speeds in the multi-gigabit range.
1.3. We intend to contribute other key overlay transports like GRE, etc
as well. The ones we are contributing at this point are the ones which
we have used most extensively and have had the most testing (~ 1.5-2 years).
2. New high res timer subsystem
Adding these new network transports to UML revealed a key issue - it
cannot meter or shape any traffic correctly as its internal timer system
is way off. Personally, I consider it a bug, however there is no "easy"
fix here. The only way to fix it is a new timer driver. Unfortunately,
it does not fix uml userspace - timers there remain off. It does fix all
kernel timer functionality - traffic shaping (both qdisc and iptables
As a side effect, this provides performance improvements for tcp and
other protocols which rely on kernel high res timers for their state
We have further scalability contributions lined up which improve network
and IO performance between 1.5 and 8 times (depending on use case),
allow hundreds of virtual interfaces per UML without performance
penalties, allow to run several hundreds (if not thousands) of UMLs per
machine, etc. All in all, it can no go where no virtualization and no
virtual networking has gone before.
However, I would prefer to take it one step at a time and get through
these first (even these are quite a lot for one "sitting").
Please send the patches as soon as possible.
I'm eager to test and merge them.
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
User-mode-linux-devel mailing list