workqueue for v2.6.36
in [Kernel]
|
Prev: [PATCH] CRED: Fix RCU warning due to previous patch fixing __task_cred()'s checks
Next: [patch] rocket: release_region or error path
From: Daniel Walker on 4 Aug 2010 12:30 On Wed, 2010-08-04 at 15:37 +0200, Tejun Heo wrote: > Hello, Linus. > > Please consider pulling from > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-linus > > to receive the concurrencey managed workqueue patches. The branch > contains 32 patches to prepare for and implement cmwq and 23 patches > fixing bugs and converting libata, async, fscache and other slow-work > users to workqueue and remove slow-work. > > The following overview section gives a brief overview. For more > detailed information, please refer to the last posting of cmwq > patchset. I haven't seen anything that shows your adding back the same expressiveness that your removing .. So I still don't think this should be merged. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: Stefan Richter on 4 Aug 2010 14:00 Daniel Walker wrote: > I haven't seen anything that shows your adding back the same > expressiveness that your removing .. So I still don't think this should > be merged. Do you mean by expressiveness the ability to hack around a suboptimally working driver in userland (by requiring the administrator to play with kernel thread priorities of dedicated worker threads)? Is it known whether this driver/ these drivers still require this hack after Tejun's patch set is applied? If yes, how about finding someone to fix this driver for good. Meanwhile, let's gets rid of the problem of having both too few and too many workers in countless present usages of the workqueue API please. -- Stefan Richter -=====-==-=- =--- --=-- http://arcgraph.de/sr/ -- 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: Daniel Walker on 4 Aug 2010 14:10 On Wed, 2010-08-04 at 19:53 +0200, Stefan Richter wrote: > Daniel Walker wrote: > > I haven't seen anything that shows your adding back the same > > expressiveness that your removing .. So I still don't think this should > > be merged. > > Do you mean by expressiveness the ability to hack around a suboptimally > working driver in userland (by requiring the administrator to play with > kernel thread priorities of dedicated worker threads)? Is it known > whether this driver/ these drivers still require this hack after Tejun's > patch set is applied? If yes, how about finding someone to fix this > driver for good. Meanwhile, let's gets rid of the problem of having > both too few and too many workers in countless present usages of the > workqueue API please. I mean by expressiveness the fact that a user can prioritize their system more fully in the current system. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: Linus Torvalds on 9 Aug 2010 16:10 On Wed, Aug 4, 2010 at 6:37 AM, Tejun Heo <tj(a)kernel.org> wrote: > > Please consider pulling from > > �git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-linus Hmm. So I pulled, because I think it is the right thing in the long run. But right now I'm bisecting a non-booting machine, and it seems to be due to the workqueue pull. It's not fully bisected yet, but the only remaining thing I actually enable is workqueues. The symptom is a machine that stops at ... dracut: Starting plymouth daemon dracut: Scanning devices sda2 for LVM volume groups dracut: Reading all physical volumes. This may take a while... dracut: Found volume group "VolGroup" using metadata type lvm2 and the next thing I'd expect to see is the mounting of the filesystem and the SElinux notifications. And I never do. I'll bisect it all the way, but thought I'd let you know. Linus -- 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: Markus Trippelsdorf on 9 Aug 2010 16:20
On Mon, Aug 09, 2010 at 01:05:31PM -0700, Linus Torvalds wrote: > On Wed, Aug 4, 2010 at 6:37 AM, Tejun Heo <tj(a)kernel.org> wrote: > > > > Please consider pulling from > > > > �git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-linus > > Hmm. So I pulled, because I think it is the right thing in the long > run. But right now I'm bisecting a non-booting machine, and it seems > to be due to the workqueue pull. > > It's not fully bisected yet, but the only remaining thing I actually > enable is workqueues. The symptom is a machine that stops at > > ... > dracut: Starting plymouth daemon > dracut: Scanning devices sda2 for LVM volume groups > dracut: Reading all physical volumes. This may take a while... > dracut: Found volume group "VolGroup" using metadata type lvm2 > > and the next thing I'd expect to see is the mounting of the filesystem > and the SElinux notifications. And I never do. > > I'll bisect it all the way, but thought I'd let you know. No need to, it's already fixed: http://lkml.org/lkml/2010/8/9/94 -- �A man who doesn't know he is in prison can never escape.� William S. Burroughs -- 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/ |