Tejun Heo wrote:
> > > My question to all of you: Should system_nrt_wq be made freezable, or
> > > should I create a new workqueue that is both freezable and
> > > non-reentrant? And if I do, which of the usages above should be
> > > converted to the new workqueue?
> >
> > As far as keys
Alan Stern wrote:
> My question to all of you: Should system_nrt_wq be made freezable, or
> should I create a new workqueue that is both freezable and
> non-reentrant? And if I do, which of the usages above should be
> converted to the new workqueue?
As far as keys are concerned, it's only
On Thu, 16 Feb 2012, Tejun Heo wrote:
> Hello,
>
> On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote:
> > Um. I don't think I can audit all the calls in the kernel that submit
> > block requests and determine which ones need to be allowed while a
> > system sleep is in progress.
>
>
On Thu, 16 Feb 2012, Tejun Heo wrote:
> Hello,
>
> On Thu, Feb 16, 2012 at 10:27:28AM -0500, Jeff Layton wrote:
> > These should all be freezable and we might even be able to get away
> > with WQ_UNBOUND for some of these.
>
> In general, I would recommend specifying as few special attribute
On Thu, 16 Feb 2012, Tejun Heo wrote:
> Hello, (cc'ing Rafael and Jens)
>
> On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote:
> > My question to all of you: Should system_nrt_wq be made freezable, or
> > should I create a new workqueue that is both freezable and
> > non-reentrant?
Hello, Jeff.
On Thu, Feb 16, 2012 at 01:59:45PM -0500, Jeff Layton wrote:
> The other problem here is that we really ought to be submitting the
> write completion handler to a workqueue that has WQ_MEM_RECLAIM set.
> Since none of the public wq's have that then I guess we'll have to make
> our
On Thu, 16 Feb 2012 09:41:34 -0500 (EST)
Alan Stern wrote:
> Folks:
>
> I recently uncovered a bug in the block layer. It uses a workqueue to
> periodically probe removable drives for media or other state changes,
> and the workqueue it uses is system_nrt_wq.
>
> The bug is that system_nrt_wq
Folks:
I recently uncovered a bug in the block layer. It uses a workqueue to
periodically probe removable drives for media or other state changes,
and the workqueue it uses is system_nrt_wq.
The bug is that system_nrt_wq is not freezable, so it keeps on running
even while the system is in the
Hello,
On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote:
> Um. I don't think I can audit all the calls in the kernel that submit
> block requests and determine which ones need to be allowed while a
> system sleep is in progress.
??? we need to do that anyway and the ones which should
On Thu, Feb 16, 2012 at 04:35:51PM +, David Howells wrote:
> The key_garbage_collector work item is marked neither freezable nor
> unfreezable that I can see.
Heh, was too brief apparently. :)
I was trying to say that if it doesn't require freezing, please don't
put it on a freezable
Hello,
On Thu, Feb 16, 2012 at 10:27:28AM -0500, Jeff Layton wrote:
> These should all be freezable and we might even be able to get away
> with WQ_UNBOUND for some of these.
In general, I would recommend specifying as few special attribute as
possible. If WQ_UNBOUND is necessary (large amount
On Thu, Feb 16, 2012 at 03:22:24PM +, David Howells wrote:
> Alan Stern wrote:
>
> > My question to all of you: Should system_nrt_wq be made freezable, or
> > should I create a new workqueue that is both freezable and
> > non-reentrant? And if I do, which of the usages above should be
>
Hello, (cc'ing Rafael and Jens)
On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote:
> My question to all of you: Should system_nrt_wq be made freezable, or
> should I create a new workqueue that is both freezable and
> non-reentrant? And if I do, which of the usages above should be
>
Folks:
I recently uncovered a bug in the block layer. It uses a workqueue to
periodically probe removable drives for media or other state changes,
and the workqueue it uses is system_nrt_wq.
The bug is that system_nrt_wq is not freezable, so it keeps on running
even while the system is in the
Hello, (cc'ing Rafael and Jens)
On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote:
My question to all of you: Should system_nrt_wq be made freezable, or
should I create a new workqueue that is both freezable and
non-reentrant? And if I do, which of the usages above should be
On Thu, Feb 16, 2012 at 03:22:24PM +, David Howells wrote:
Alan Stern st...@rowland.harvard.edu wrote:
My question to all of you: Should system_nrt_wq be made freezable, or
should I create a new workqueue that is both freezable and
non-reentrant? And if I do, which of the usages
Hello,
On Thu, Feb 16, 2012 at 10:27:28AM -0500, Jeff Layton wrote:
These should all be freezable and we might even be able to get away
with WQ_UNBOUND for some of these.
In general, I would recommend specifying as few special attribute as
possible. If WQ_UNBOUND is necessary (large amount
On Thu, 16 Feb 2012, Tejun Heo wrote:
Hello, (cc'ing Rafael and Jens)
On Thu, Feb 16, 2012 at 09:41:34AM -0500, Alan Stern wrote:
My question to all of you: Should system_nrt_wq be made freezable, or
should I create a new workqueue that is both freezable and
non-reentrant? And if I
On Thu, Feb 16, 2012 at 04:35:51PM +, David Howells wrote:
The key_garbage_collector work item is marked neither freezable nor
unfreezable that I can see.
Heh, was too brief apparently. :)
I was trying to say that if it doesn't require freezing, please don't
put it on a freezable
On Thu, 16 Feb 2012, Tejun Heo wrote:
Hello,
On Thu, Feb 16, 2012 at 10:27:28AM -0500, Jeff Layton wrote:
These should all be freezable and we might even be able to get away
with WQ_UNBOUND for some of these.
In general, I would recommend specifying as few special attribute as
Hello,
On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote:
Um. I don't think I can audit all the calls in the kernel that submit
block requests and determine which ones need to be allowed while a
system sleep is in progress.
??? we need to do that anyway and the ones which should go
On Thu, 16 Feb 2012, Tejun Heo wrote:
Hello,
On Thu, Feb 16, 2012 at 11:37:33AM -0500, Alan Stern wrote:
Um. I don't think I can audit all the calls in the kernel that submit
block requests and determine which ones need to be allowed while a
system sleep is in progress.
??? we need
Hello, Jeff.
On Thu, Feb 16, 2012 at 01:59:45PM -0500, Jeff Layton wrote:
The other problem here is that we really ought to be submitting the
write completion handler to a workqueue that has WQ_MEM_RECLAIM set.
Since none of the public wq's have that then I guess we'll have to make
our own?
Alan Stern st...@rowland.harvard.edu wrote:
My question to all of you: Should system_nrt_wq be made freezable, or
should I create a new workqueue that is both freezable and
non-reentrant? And if I do, which of the usages above should be
converted to the new workqueue?
As far as keys are
Tejun Heo t...@kernel.org wrote:
My question to all of you: Should system_nrt_wq be made freezable, or
should I create a new workqueue that is both freezable and
non-reentrant? And if I do, which of the usages above should be
converted to the new workqueue?
As far as keys are
On Thu, 16 Feb 2012 08:29:51 -0800
Tejun Heo t...@kernel.org wrote:
Hello,
On Thu, Feb 16, 2012 at 10:27:28AM -0500, Jeff Layton wrote:
These should all be freezable and we might even be able to get away
with WQ_UNBOUND for some of these.
In general, I would recommend specifying as
26 matches
Mail list logo
