Zack's Kernel News

Driver Dependencies

Rafael J. Wysocki wanted to create a new set of dependencies associated with the Linux kernel: specifically, the dependency that one device and its associated driver might have for another. His idea was that a device and its driver would register a dependency on another device and driver, thus linking them together logically. This way, an attempt by the user to unload a driver that was needed by another device could be forestalled by the system. The driver in question could only be unloaded after all other drivers released their links to it.

Tomeu Vizoso thought this would be a great idea, as long as the dependencies could be figured out properly. In particular, Rafael wanted to distinguish between two types of dependency links between drivers: those that were created when the device was registered with the system and those that only came into being when the device probed the system to see what other hardware was available. Tomeu felt there was a strong danger of code duplication in the latter case between the probing code and the linking code. Also, he felt that if the kernel couldn't be refactored to avoid that duplication, it would be a tough problem to keep both sets of code in sync with each other.

Rafael replied, "That almost certainly is going to be a fair amount of work, but that doesn't mean we should avoid doing it. If it leads to better code eventually, it's worth doing."

Tomeu was also concerned that Rafael wanted to make things too complicated by having drivers construct dependency links before probing the system based on whatever information was already available. He thought it would be easier simply to do the probe. Rafael replied that it would be easier to understand the order of operations if the system used information that was already available, although he acknowledged that if it proved very difficult to collect that information, it wouldn't be worth it.

Meanwhile, Linus Walleij said he liked Rafael's proposal very much, although he also pointed out that circular dependencies could become a problem.

Greg Kroah-Hartman also liked Rafael's plan and thought that Rafael had also successfully identified the implementation requirements.

Thierry Reding was also very supportive. He said, "I think this would be a huge step towards making the kernel more robust with little driver or subsystem code having to be duplicated. Currently most provider/consumer subsystems are fragile in that there isn't proper reference counting. Many subsystems will happily allow you to remove any of the provider, regardless of whether or not it has consumers. Most of the subsystems will make sure that modules can't be unloaded, but beyond that won't be able to prevent drivers from being unbound (either when a device is unplugged or unbound via sysfs). Even with proper reference counting there is no easy way to deal with devices going away (you'd need some sort of revoke semantics implemented for all providers, and consumers must be able to handle that situation gracefully)."

Thierry added, "I can also imagine subsystems where a reliable mechanism is in place to properly hotplug and -unplug providers. The good thing about the functional dependencies mechanism you propose here is that it's an optional mechanism that drivers use from ->probe(). Subsystems where a better mechanism exists can simply choose to do without functional dependencies."

Elsewhere, Andrzej Hajda pointed out an issue he had with Rafael's idea: He felt that certain drivers should be able to have "weak" dependencies, where the driver could still function in a limited capacity even if some of its dependencies weren't met, although later he acknowledged that, "It should be enough if provider notifies consumers that the resource will be unavailable."

There were various technical questions and comments, mostly having to do with exactly how and when drivers might communicate their dependencies to each other. Eventually Rafael posted some actual code to implement what he was talking about, and the conversation petered out.

It seems as though, in general, nobody objects to drivers having these sorts of dynamic and enforced dependencies. The issues seem to be code duplication and the need to keep specific behaviors sane and usable. It seems as though once the code gets a bit further along, it will sail into the main source tree.

Speeding Up the Balloons

Liang Li wanted to improve the speed at which the VirtIO balloon driver could inflate and deflate. A balloon driver is one technique of allowing a virtual Linux system to gain access to more memory. To the virtual system, the driver gives the appearance of using a lot of memory, while in fact the memory isn't used at all and is simply available to the host to use for other processes. When the virtual system needs access to more memory, the balloon driver seems to "free up" some of the memory it has allocated. In fact, the newly available memory is being allocated by the host. It's all just a blue pill to let the virtual system think it's not plugged into a Matrix feeding pod.

However, the act of maintaining that illusion is slow, at least according to Liang. To inflate the balloon to 3G on a virtual system that believed itself to have 4G available took about 1.5 seconds on Liang's setup. He posted a patch to reduce this to a ninth of the speed, down to 175 milliseconds. The key, he said, was to avoid passing heavyweight page frame numbers around and to use a sleek bitmap instead.

Cornelia Huck had some technical suggestions, and Michael S. Tsirkin felt that Liang's implementation had some race conditions that needed to be ironed out. After some back and forth, Liang posted another patch that addressed Michael's races, but at a speed cost. The new code took 338 milliseconds instead of 175. This didn't seem like a necessary cost to Michael, and the two of them went back and forth on it. Michael also submitted his own versions of the patch to illustrate some of his implementation ideas.

At some point the discussion petered out. Clearly, though, even at 338 milliseconds, Liang's patch is a big improvement over the existing code. With modern corporations running vast farms of virtualized systems, this kind of speedup makes a big difference.

Zack Brown

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Kernel News

    Zack Brown looks at improving memory management, simplifying(ish) the Kernel Build System, and detecting firmware crashes.

  • Kernel News

    Chronicler Zack Brown reports on the latest news, views, dilemmas, and developments within the Linux kernel community.

  • Kernel News

    Chronicler Zack Brown reports on the latest news, views, dilemmas, and developments within the Linux kernel community.

  • ZACK'S KERNEL NEWS
  • Linux Boot Process

    If you want to troubleshoot startup issues, you need a clear understanding of how Linux boots.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News