linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: [patch] Workqueue Abstraction, 2.5.40-H7
Date: Tue, 1 Oct 2002 18:24:50 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0210011653370.28821-102000@localhost.localdomain> (raw)

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3070 bytes --]


the attached (compressed) patch is the next iteration of the workqueue
abstraction. There are two major categories of changes:

  - a much improved (i hope) core framework

  - (almost) complete conversion of existing drivers to the new framework.

1) The framework improvements include:

 - per-CPU queueing support.

on SMP there is a per-CPU worker thread (bound to its CPU) and per-CPU
work queues - this feature is completely transparent to workqueue-users.  
keventd automatically uses this feature. XFS can now update to work-queues
and have the same per-CPU performance as it had with its per-CPU worker
threads.

 - delayed work submission

there's a new queue_delayed_work(wq, work, delay) function and a new
schedule_delayed_work(work, delay) function. The later one is used to
correctly fix former tq_timer users. I've reverted those changes in 2.5.40
that changed tq_timer uses to schedule_work() - eg. in the case of
random.c or the tty flip queue it was definitely the wrong thing to do.

delayed work means a timer embedded in work_t. I considered using split
work_t and delayed_work_t types, but lots of code actively uses
task-queues in both delayed and non-delayed mode, so i went for the more
generic approach that allows both methods of work submission. Delayed
timers do not cause any other overhead in the normal submission path
otherwise.

 - multithreaded run_workqueue() implementation

the run_workqueue() function can now be called from multiple contexts, and
a worker thread will only use up a single entryy - this property is used
by the flushing code, and can potentially be used in the future to extend
the number of per-CPU worker threads.

 - more reliable flushing

there's now a 'pending work' counter, which is used to accurately detect
when the last work-function has finished execution. It's also used to
correctly flush against timed requests. I'm not convinced whether the old
keventd implementation got this detail right.

 - i switched the arguments of the queueing function(s) per Jeff's
   suggestion, it's more straightforward this way.


2) driver fixes.

i have converted almost every affected driver to the new framework. This
cleaned up tons of code. I also fixed a number of drivers that were still
using BHs (these drivers did not compile in 2.5.40).

while this means lots of changes, it might ease the QA decision whether to
put this patch into 2.5.

The pach converts roughly 80% of all tqueue-using code to workqueues - and
all the places that are not converted to workqueues yet are places that do
not compile in vanilla 2.5.40 anyway, due to unrelated changes. I've
converted a fair number of drivers that do not compile in 2.5.40, and i
think i've managed to convert every driver that compiles under 2.5.40.

i've tested the patch on 2.5.40, UP and SMP x86, boots & works just fine.

I've also attached maxi-config, which is a pretty large .config - this
config file compiles the kernel just fine. (it's too large to be booted
though.) No workqueue/taskqueue related warning messages or compile
errors.

	Ingo

[-- Attachment #2: Type: APPLICATION/x-bzip2, Size: 39848 bytes --]

[-- Attachment #3: Type: APPLICATION/x-bzip2, Size: 6873 bytes --]

             reply	other threads:[~2002-10-01 16:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-01 16:24 Ingo Molnar [this message]
2002-10-01 17:55 ` [patch] Workqueue Abstraction, 2.5.40-H7 Kai Germaschewski
2002-10-01 21:27   ` Ingo Molnar
2002-10-01 18:04 ` Jeff Garzik
2002-10-01 18:52   ` Ingo Molnar
2002-10-01 21:06     ` Jeff Garzik
2002-10-01 21:30       ` Ingo Molnar
2002-10-01 19:16 ` Linus Torvalds
2002-10-01 19:53   ` Linus Torvalds
2002-10-01 21:32 ` Kristian Hogsberg
2002-10-03 18:44   ` Ingo Molnar
2002-10-04 23:20     ` Kristian Hogsberg
2002-10-02  4:22 ` Christoph Hellwig
2002-10-01 21:31   ` Ingo Molnar
2002-10-02  8:22 ` Oleg Drokin
2002-10-08  3:50   ` Jeff Dike
2002-10-01 18:52 Marc-Christian Petersen
2002-10-02  3:58 ` Christoph Hellwig
2002-10-01 20:29 Ingo Molnar
2002-10-01 20:49 ` Linus Torvalds
2002-10-01 21:21   ` Ingo Molnar
2002-10-02  3:23     ` Miles Bader
2002-10-02 19:18     ` Randy.Dunlap
2002-10-01 21:09 ` Jes Sorensen
2002-10-01 21:35   ` Ingo Molnar
2002-10-03  1:38 ` Kevin O'Connor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0210011653370.28821-102000@localhost.localdomain \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).