KernelNewbies
  • Comments
  • Immutable Page
  • Menu
    • Navigation
    • RecentChanges
    • FindPage
    • Local Site Map
    • Help
    • HelpContents
    • HelpOnMoinWikiSyntax
    • Display
    • Attachments
    • Info
    • Raw Text
    • Print View
    • Edit
    • Load
    • Save
  • Login

Kernel Hacking

  • Frontpage

  • Kernel Hacking

  • Kernel Documentation

  • Kernel Glossary

  • FAQ

  • Found a bug?

  • Kernel Changelog

  • Upstream Merge Guide

Projects

  • KernelJanitors

  • KernelMentors

  • KernelProjects

Community

  • Why a community?

  • Regional Kernelnewbies

  • Personal Pages

  • Upcoming Events

References

  • Mailing Lists

  • Related Sites

  • Programming Links

Wiki

  • Recent Changes

  • Site Editors

  • Side Bar

  • Tips for Editors

  • Hosted by WikiWall

Navigation

  • RecentChanges
  • FindPage
  • HelpContents
Revision 3 as of 2016-02-10 20:12:57
KernelNewbies:
  • Tejun_Heo

Contact info

Email: MailTo(tj AT kernel DOT org)

Task: Convert create_workqueue() usages in drivers/staging/rtl8192[eu]

Description

There are four usages of create_workqueue() in rtl8192[eu] drivers. Convert them to use system_wq or alloc_workqueue(). create_workqueue() maps to per-cpu workqueue (this is the default flavor) with WQ_MEM_RECLAIM set and maximum concurrency of 1, so a workqueue created with create_workqueue() has the following properties.

  1. Work items are guaranteed to be executed regardless of memory pressure and thus can be depended upon from memory reclaim. B. Work items queued to a specific CPU using queue_work_on() will execute on that cpu. Work items queued via queue_work() will prefer the queueing CPU but the locality is not guaranteed. C. Work items queued on the same CPU will be executed in order; however, there's no ordering defined between work items executing on different CPUs.

The conversion should pick the option which minimally fits the use case. The order of preferences is

  1. system_wq
  2. Other system_*wq which fits the usage minimally.
  3. alloc_workqueue() with the minimal attributes specified.

The questions to ask during conversion are roughly

* If the work items hosted by a workqueue are depeneded upon during memory reclaim, it needs to stay a separate workqueue and retain WQ_MEM_RECLAIM. Note that a workqueue with WQ_MEM_RECLAIM only guarantees forward progress of a single work item at a given time meaning that if a work item which is depended upon during memory reclaim depends on another work item, the two need to put into separate workqueues, each with WQ_MEM_RECLAIM.

Hint: Wireless drivers aren't depended upon during memory reclaim.

  • Do the work items need other specific attributes - WQ_HIGHPRI, WQ_CPU_INTENSIVE and so on? Please consult Documentation/workqueue.txt on details on each attribute.
  • Do the work items need to be flushed as a whole? e.g. if work items are created dynamically and freed on execution but need to be flushed, they need a dedicated workqueue to serve as a flush domain.
  • Do the work items need to be limited in concurrency? If the work items are created dynamically and can be numerous, they need to be queued on a separate workqueue with a reasonable concurrency limit. Note that the concurrency limit is per cpu or numa node and exist primarily to prevent run-away work items from overwhelming the system.

Occasionally, work items on a per-cpu workqueue may require execution ordering requiring the concurrency to be set at 1.

  • MoinMoin Powered
  • Python Powered
  • GPL licensed
  • Valid HTML 4.01