workqueue: concurrency managed workqueue, take#5
in [Kernel]
|
Prev: [PATCH 02/30] acpi: use queue_work_on() instead of binding workqueue worker to cpu0
Next: [PATCH 6/6] hvc_console: Fix race between hvc_close and hvc_remove
From: Daniel Walker on 14 Jun 2010 18:50 On Tue, 2010-06-15 at 00:44 +0200, Tejun Heo wrote: > On 06/15/2010 12:35 AM, Daniel Walker wrote: > > What is you definition of "concurrency" ? and explain try to explain it > > in terms of your patchset. > > How many workers are concurrently executing? What else? Eh... I'll > write up another summary tomorrow. Let's talk it there. I'd suggest If you write up another description try to not use the word concurrency .. That term can be used for all sorts of things, and it doesn't covey enough detail for anyone to know what your implementation is actually doing. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 14 Jun 2010 18:50 On 06/15/2010 12:35 AM, Daniel Walker wrote: > What is you definition of "concurrency" ? and explain try to explain it > in terms of your patchset. How many workers are concurrently executing? What else? Eh... I'll write up another summary tomorrow. Let's talk it there. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 14 Jun 2010 19:00 On 06/15/2010 12:49 AM, Daniel Walker wrote: > On Tue, 2010-06-15 at 00:44 +0200, Tejun Heo wrote: >> On 06/15/2010 12:35 AM, Daniel Walker wrote: >>> What is you definition of "concurrency" ? and explain try to explain it >>> in terms of your patchset. >> >> How many workers are concurrently executing? What else? Eh... I'll >> write up another summary tomorrow. Let's talk it there. > > I'd suggest If you write up another description try to not use the word > concurrency .. That term can be used for all sorts of things, and it > doesn't covey enough detail for anyone to know what your implementation > is actually doing. So is "manage" and "level of concurrency" is often used to describe exactly this type of property. I'll try to be clear. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 14 Jun 2010 19:10 On Tue, 15 Jun 2010 00:43:17 +0200 Tejun Heo <tj(a)kernel.org> wrote: > Hello, > > On 06/15/2010 12:35 AM, Andrew Morton wrote: > > Nobody's going to remember all that stuff except yourself, and the info > > might be out of date. So please update and maintain that information > > and retain it with the patchset. > > > > eg: "<NEED SOME BACKING NUMBERS>". And "Please read the patch > > description of the last patch for more details" is out of date. > > > > Because right now I have a bunch of code in my inbox and little > > (actually "no") idea why anyone might want to merge it into anything. > > > > Trying to review a large patchset when you don't have an overall > > picture of what it's trying to do and how it's trying to do it is > > rather painful - you have to work all that stuff out from the > > implementation. It's also error-prone if the implementation doesn't > > implement that which the author thinks it implements (ie: if it has > > design bugs). > > Well, basics of the whole thing didn't change all that much since the > first take and most people on cc list were cc'd on each take. The > biggest reason I'm still carrying the whole patchset is due to the > scheduler changes. The numbers are in the third take (which you can > follow the links to find out). Anyways, I'll write up another summary > tomorrow. > Thanks. I don't think I've looked at these patches at all since the first version, and I'd like to. That was many many thousands of patches ago and I don't remember anything useful at all about them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeff Garzik on 14 Jun 2010 21:30
On 06/14/2010 05:37 PM, Tejun Heo wrote: > Hello, all. > > This is the fifth take of cmwq (concurrency managed workqueue) > patchset. It's on top of v2.6.35-rc3 + sched/core patches. Git tree > is available at > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-cmwq > > Changes from the last take[L] are... > > * fscache patches are omitted for now. > > * The patchset is rebased on cpu_stop + sched/core, which now includes > all the necessary scheduler patches. cpu_stop already reimplements > stop_machine so that it doesn't use RT workqueue, so this patchset > simply drops RT wq support. > > * __set_cpus_allowed() was determined to be unnecessary with recent > scheduler changes. On cpu re-onlining, cmwq now kills all idle > workers and tells busy ones to rebind after finishing the current > work by scheduling a dedicated work. This allows managing proper > cpu binding without adding overhead to hotpath. > > * Oleg's clear work->data patch moved at the head of the queue and now > lives in the for-next branch which will be pushed to mainline on the > next merge window. > > * Applied Oleg's review. > > * Comments updated as suggested. > > * work_flags_to_color() replaced w/ get_work_color() > > * nr_cwqs_to_flush bug which could cause premature flush completion > fixed. > > * Replace rewind + list_for_each_entry_safe_continue() w/ > list_for_each_entry_safe_from(). > > * Don't directly write to *work_data_bits() but use __set_bit() > instead. > > * Fixed cpu hotplug exclusion bug. > > * Other misc tweaks. > > Now that all scheduler bits are in place, I'll keep the tree stable > and publish it to linux-next soonish, so this hopefully is the last of > exhausting massive postings of this patchset. > > Jeff, Arjan, I think it'll be best to route the libata and async > patches through wq tree. Would that be okay? ACK for libata bits routing through wq tree... you know I support this work, as libata (and the kernel, generally speaking) has needed something like this for a long time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |