usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue
RFC 1/1 usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue
alloc_ordered_workqueue replaces the deprecatedcreate_singlethread_workqueue.
The workqueue "workqueue" has multiple workitems which may require ordering. Hence, a dedicated ordered workqueue has been used. Since the workqueue is not being used on a memory reclaim path, WQ_MEM_RECLAIM has not been set.
Can the workitems run concurrently? Is the ordering among work items necessary?
Thanks.
--- drivers/usb/host/u132-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/u132-hcd.c +1 -1
@@ -3206,7 +3206,7 @@ static int __init u132_hcd_init(void)if (usb_disabled ())return -ENODEV ;printk (KERN_INFO "driver %s\n" , hcd_name); - workqueue =create_singlethread_workqueue ("u132" ); + workqueue =alloc_ordered_workqueue ("u132" ,0 ); retval =platform_driver_register (&u132_platform_driver);return retval; }
--
2.1.4
Quoted 4 lines · Bhaktipriya Shridhar
The workqueue "workqueue" has multiple workitems which may require ordering. Hence, a dedicated ordered workqueue has been used. Since the workqueue is not being used on a memory reclaim path,
WQ_MEM_RECLAIMhas not been set.
That is incorrect. The work queue is used by the HCD to handle TDs, which are parts of basic IO. The HCD in turn is used by usb-storage and uas, which are block drivers and those are obviously used on the memory reclaim path.
HTH
Oliver
Hello, Oliver.
Quoted 10 lines · Oliver Neukum
Quoted 4 lines · Bhaktipriya Shridhar
The workqueue "workqueue" has multiple workitems which may require ordering. Hence, a dedicated ordered workqueue has been used. Since the workqueue is not being used on a memory reclaim path,
WQ_MEM_RECLAIMhas not been set.That is incorrect. The work queue is used by the HCD to handle TDs, which are parts of basic IO. The HCD in turn is used by usb-storage and uas, which are block drivers and those are obviously used on the memory reclaim path.
Hmm... I didn't know the whole USB stack could operate without allocating memory. Does usb stack have mempools and stuff all the way through?
Thanks.
Signature · 1 line
tejun
Quoted 9 lines · Tejun Heo
Hello, Oliver.
Quoted 6 lines · Oliver Neukum
Quoted 4 lines · Bhaktipriya Shridhar
The workqueue "workqueue" has multiple workitems which may require ordering. Hence, a dedicated ordered workqueue has been used. Since the workqueue is not being used on a memory reclaim path,
WQ_MEM_RECLAIMhas not been set.
Quoted 8 lines
Quoted 4 lines
That is incorrect. The work queue is used by the HCD to handle TDs, which are parts of basic IO. The HCD in turn is used by usb-storage and uas, which are block drivers and those are obviously used on the memory reclaim path.
Hmm... I didn't know the whole USB stack could operate without allocating memory. Does usb stack have mempools and stuff all the way through?
No -- the USB stack does need to allocate memory in order to operate. But it is careful to use GFP_NOIO or GFP_ATOMIC for allocations that might be on the block-device path.
Alan Stern
Hello, Alan.
Quoted 7 lines · Alan Stern
Quoted 3 lines
Hmm... I didn't know the whole USB stack could operate without allocating memory. Does usb stack have mempools and stuff all the way through?
No -- the USB stack does need to allocate memory in order to operate. But it is careful to use
GFP_NOIOorGFP_ATOMICfor allocations that might be on the block-device path.
Hmm... That doesn't really make them dependable during memory reclaim. What happens when those allocations fail?
Thanks.
Signature · 1 line
tejun
Quoted 7 lines · Tejun Heo
Hello, Alan.
Quoted 4 lines · Alan Stern
Quoted 3 lines
Hmm... I didn't know the whole USB stack could operate without allocating memory. Does usb stack have mempools and stuff all the way through?
Quoted 5 lines
Quoted 3 lines
No -- the USB stack does need to allocate memory in order to operate. But it is careful to use
GFP_NOIOorGFP_ATOMICfor allocations that might be on the block-device path.Hmm... That doesn't really make them dependable during memory reclaim.
True. But it does mean that they can't cause a deadlock by waiting indefinitely for some other memory to be paged out to the very device they are on the access pathway for.
Quoted 1 line
What happens when those allocations fail?
The same thing that happens when any allocation fails -- the original I/O request fails with -ENOMEM or the equivalent. In the case of usb-storage, this is likely to trigger error recovery, which will need to allocate memory of its own... A bad situation to get into.
Alan Stern
Hello, Alan.
Quoted 6 lines · Alan Stern
Quoted 1 line
Hmm... That doesn't really make them dependable during memory reclaim.
True. But it does mean that they can't cause a deadlock by waiting indefinitely for some other memory to be paged out to the very device they are on the access pathway for.
Quoted 6 lines
Quoted 1 line
What happens when those allocations fail?
The same thing that happens when any allocation fails -- the original I/O request fails with
-ENOMEMor the equivalent. In the case of usb-storage, this is likely to trigger error recovery, which will need to allocate memory of its own... A bad situation to get into.
All that would do is deferring the deadlock, right? I'm not sure it makes a lot of sense to protect an IO path against memory pressure half-way. It either can be depended during memory reclaim or it can't. The use of GFP_NOIO / ATOMIC is probably increases the chance of IO errors under moderate memory pressure too when there are dependable memory backing devices (and there better be) which can push things forward if called upon.
Can MM people please chime in? The question is about USB stoage devices and memory reclaim. USB doesn't guarantee forward progress under memory pressure but tries a best-effort attempt with GFP_NOIO and ATOMIC. Is this the right thing to do?
Thanks.
Signature · 1 line
tejun
Quoted 16 lines · Tejun Heo
Hello, Alan.
Quoted 6 lines · Alan Stern
Quoted 1 line
Hmm... That doesn't really make them dependable during memory reclaim.
True. But it does mean that they can't cause a deadlock by waiting indefinitely for some other memory to be paged out to the very device they are on the access pathway for.
Quoted 6 lines
Quoted 1 line
What happens when those allocations fail?
The same thing that happens when any allocation fails -- the original I/O request fails with
-ENOMEMor the equivalent. In the case of usb-storage, this is likely to trigger error recovery, which will need to allocate memory of its own... A bad situation to get into.
Quoted 4 lines
All that would do is deferring the deadlock, right? I'm not sure it makes a lot of sense to protect an IO path against memory pressure half-way. It either can be depended during memory reclaim or it can't.
Completely agreed! If the rescuer thread can block on a memory allocation be it GFP_NOIO or others it is basically useless.
Quoted 9 lines
The use of
GFP_NOIO/ ATOMIC is probably increases the chance of IO errors under moderate memory pressure too when there are dependable memory backing devices (and there better be) which can push things forward if called upon.Can MM people please chime in? The question is about USB stoage devices and memory reclaim. USB doesn't guarantee forward progress under memory pressure but tries a best-effort attempt with
GFP_NOIOand ATOMIC. Is this the right thing to do?
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Signature · 2 lines
Michal Hocko SUSE Labs
Hello,
Quoted 7 lines · Michal Hocko
Quoted 4 lines
All that would do is deferring the deadlock, right? I'm not sure it makes a lot of sense to protect an IO path against memory pressure half-way. It either can be depended during memory reclaim or it can't.
Completely agreed! If the rescuer thread can block on a memory allocation be it
GFP_NOIOor others it is basically useless.
...
Quoted 7 lines
Quoted 4 lines
Can MM people please chime in? The question is about USB stoage devices and memory reclaim. USB doesn't guarantee forward progress under memory pressure but tries a best-effort attempt with
GFP_NOIOand ATOMIC. Is this the right thing to do?If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing GFP_NOIO and GFP_ATOMIC are doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?
Thanks.
Signature · 1 line
tejun
Quoted 19 lines · Tejun Heo
Hello,
Quoted 7 lines · Michal Hocko
Quoted 4 lines
All that would do is deferring the deadlock, right? I'm not sure it makes a lot of sense to protect an IO path against memory pressure half-way. It either can be depended during memory reclaim or it can't.
Completely agreed! If the rescuer thread can block on a memory allocation be it
GFP_NOIOor others it is basically useless....
Quoted 7 lines
Quoted 4 lines
Can MM people please chime in? The question is about USB stoage devices and memory reclaim. USB doesn't guarantee forward progress under memory pressure but tries a best-effort attempt with
GFP_NOIOand ATOMIC. Is this the right thing to do?If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Quoted 7 lines
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?
I agree that USB's approach to memory allocation won't prevent failures when there is severe pressure.
However, is it possible that the _type_ of failure might be more transparent? With GFP_NOIO, you end up with a cascading series of allocation errors and it's obvious that something has gone very wrong. If we were to switch to GFP_KERNEL, page-out could lead to deadlock with no diagnostics (except perhaps for a watchdog warning).
Regardless, I would like to hear Oliver's thoughts.
Alan Stern
Quoted 29 lines · Alan Stern
Quoted 19 lines · Tejun Heo
Hello,
Quoted 7 lines · Michal Hocko
Quoted 4 lines
All that would do is deferring the deadlock, right? I'm not sure it makes a lot of sense to protect an IO path against memory pressure half-way. It either can be depended during memory reclaim or it can't.
Completely agreed! If the rescuer thread can block on a memory allocation be it
GFP_NOIOor others it is basically useless....
Quoted 7 lines
Quoted 4 lines
Can MM people please chime in? The question is about USB stoage devices and memory reclaim. USB doesn't guarantee forward progress under memory pressure but tries a best-effort attempt with
GFP_NOIOand ATOMIC. Is this the right thing to do?If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Quoted 7 lines
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?
Quoted 2 lines
I agree that USB's approach to memory allocation won't prevent failures when there is severe pressure.
Or even worse, silent hangs for GFP_NOIO requests. If the allocation size that is issued from that context is not large (basically < order-4) then the allocation would be retried basically for ever without invoking the OOM killer. Now, this is rather unlikely to become a real problem unless there is a serious flood of these GFP_NOIO allocation requests. But the main point remains. GFP_NOIO doesn't guanratee a forward progress. Success of such an allocation depends on on a different context with the full reclaim capabilities (including the OOM killer).
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 7 lines · Tejun Heo
Hello,
Quoted 2 lines
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers
It cannot. The IO must be described to the hardware with a data structure in memory.
Quoted 5 lines
are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?
We had actual deadlocks with GFP_KERNEL. It seems to me that the SCSI layer can deal with IO that cannot be completed due to a lack of memory at least somewhat, but a deadlock within a driver would obviously be deadly. So I don't think that mempools would remove the need for GFP_NOIO as there are places in usbcore we cannot enter the page laundering path from. They are an additional need.
Regards
Oliver
Quoted 18 lines · Oliver Neukum
Quoted 7 lines · Tejun Heo
Hello,
Quoted 2 lines
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers
It cannot. The IO must be described to the hardware with a data structure in memory.
Quoted 5 lines
are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?
Quoted 6 lines
We had actual deadlocks with
GFP_KERNEL. It seems to me that the SCSI layer can deal with IO that cannot be completed due to a lack of memory at least somewhat, but a deadlock within a driver would obviously be deadly. So I don't think that mempools would remove the need forGFP_NOIOas there are places in usbcore we cannot enter the page laundering path from. They are an additional need.
OK, I guess there is some misunderstanding here. I believe that Tejun wasn't arguing to drop GFP_NOIO. It might be really needed for the dead lock avoidance. No question about that. The whole point is that WQ_RECLAIM might be completely pointless because a rescuer wouldn't help much if the work item would do GFP_NOIO and get stuck in the page allocator.
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 26 lines · Michal Hocko
Quoted 18 lines · Oliver Neukum
Quoted 7 lines · Tejun Heo
Hello,
Quoted 2 lines
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers
It cannot. The IO must be described to the hardware with a data structure in memory.
Quoted 5 lines
are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?Quoted 6 lines
We had actual deadlocks with
GFP_KERNEL. It seems to me that the SCSI layer can deal with IO that cannot be completed due to a lack of memory at least somewhat, but a deadlock within a driver would obviously be deadly. So I don't think that mempools would remove the need forGFP_NOIOas there are places in usbcore we cannot enter the page laundering path from. They are an additional need.
Quoted 6 lines
OK, I guess there is some misunderstanding here. I believe that Tejun wasn't arguing to drop
GFP_NOIO. It might be really needed for the dead lock avoidance. No question about that. The whole point is thatWQ_RECLAIMmight be completely pointless because a rescuer wouldn't help much if the work item would doGFP_NOIOand get stuck in the page allocator.
But that can be a problem only if the items on the work queue are actually run and without WQ_MEM_RECLAIM that guarantee cannot be made. We can deal with failures of memory allocation. But the requests must actually terminate.
Regards
Oliver
Quoted 34 lines · Oliver Neukum
Quoted 26 lines · Michal Hocko
Quoted 18 lines · Oliver Neukum
Quoted 7 lines · Tejun Heo
Hello,
Quoted 2 lines
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers
It cannot. The IO must be described to the hardware with a data structure in memory.
Quoted 5 lines
are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?Quoted 6 lines
We had actual deadlocks with
GFP_KERNEL. It seems to me that the SCSI layer can deal with IO that cannot be completed due to a lack of memory at least somewhat, but a deadlock within a driver would obviously be deadly. So I don't think that mempools would remove the need forGFP_NOIOas there are places in usbcore we cannot enter the page laundering path from. They are an additional need.Quoted 6 lines
OK, I guess there is some misunderstanding here. I believe that Tejun wasn't arguing to drop
GFP_NOIO. It might be really needed for the dead lock avoidance. No question about that. The whole point is thatWQ_RECLAIMmight be completely pointless because a rescuer wouldn't help much if the work item would doGFP_NOIOand get stuck in the page allocator.
Quoted 4 lines
But that can be a problem only if the items on the work queue are actually run and without
WQ_MEM_RECLAIMthat guarantee cannot be made. We can deal with failures of memory allocation. But the requests must actually terminate.
I think you have missed my point. So let me ask differently. What is the difference between your work item not running at all or looping endlessly with GFP_NOIO inside the page allocator? If that particular work item is necessary for the further progress then the system is screwed one way or another.
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 40 lines · Michal Hocko
Quoted 34 lines · Oliver Neukum
Quoted 26 lines · Michal Hocko
Quoted 18 lines · Oliver Neukum
Quoted 7 lines · Tejun Heo
Hello,
Quoted 2 lines
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers
It cannot. The IO must be described to the hardware with a data structure in memory.
Quoted 5 lines
are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?Quoted 6 lines
We had actual deadlocks with
GFP_KERNEL. It seems to me that the SCSI layer can deal with IO that cannot be completed due to a lack of memory at least somewhat, but a deadlock within a driver would obviously be deadly. So I don't think that mempools would remove the need forGFP_NOIOas there are places in usbcore we cannot enter the page laundering path from. They are an additional need.Quoted 6 lines
OK, I guess there is some misunderstanding here. I believe that Tejun wasn't arguing to drop
GFP_NOIO. It might be really needed for the dead lock avoidance. No question about that. The whole point is thatWQ_RECLAIMmight be completely pointless because a rescuer wouldn't help much if the work item would doGFP_NOIOand get stuck in the page allocator.Quoted 4 lines
But that can be a problem only if the items on the work queue are actually run and without
WQ_MEM_RECLAIMthat guarantee cannot be made. We can deal with failures of memory allocation. But the requests must actually terminate.
Quoted 5 lines
I think you have missed my point. So let me ask differently. What is the difference between your work item not running at all or looping endlessly with
GFP_NOIOinside the page allocator? If that particular work item is necessary for the further progress then the system is screwed one way or another.
The key difference is that I could give the right parameters to the kmalloc() call. If it doesn't run, I am surely screwed. Thus I conclude that WQ_RECLAIM needs to be set.
Regards
Oliver
Quoted 47 lines · Oliver Neukum
Quoted 40 lines · Michal Hocko
Quoted 34 lines · Oliver Neukum
Quoted 26 lines · Michal Hocko
Quoted 18 lines · Oliver Neukum
Quoted 7 lines · Tejun Heo
Hello,
Quoted 2 lines
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers
It cannot. The IO must be described to the hardware with a data structure in memory.
Quoted 5 lines
are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?Quoted 6 lines
We had actual deadlocks with
GFP_KERNEL. It seems to me that the SCSI layer can deal with IO that cannot be completed due to a lack of memory at least somewhat, but a deadlock within a driver would obviously be deadly. So I don't think that mempools would remove the need forGFP_NOIOas there are places in usbcore we cannot enter the page laundering path from. They are an additional need.Quoted 6 lines
OK, I guess there is some misunderstanding here. I believe that Tejun wasn't arguing to drop
GFP_NOIO. It might be really needed for the dead lock avoidance. No question about that. The whole point is thatWQ_RECLAIMmight be completely pointless because a rescuer wouldn't help much if the work item would doGFP_NOIOand get stuck in the page allocator.Quoted 4 lines
But that can be a problem only if the items on the work queue are actually run and without
WQ_MEM_RECLAIMthat guarantee cannot be made. We can deal with failures of memory allocation. But the requests must actually terminate.Quoted 5 lines
I think you have missed my point. So let me ask differently. What is the difference between your work item not running at all or looping endlessly with
GFP_NOIOinside the page allocator? If that particular work item is necessary for the further progress then the system is screwed one way or another.
Quoted 3 lines
The key difference is that I could give the right parameters to the
kmalloc()call. If it doesn't run, I am surely screwed. Thus I conclude thatWQ_RECLAIMneeds to be set.
Just to make sure I understand. So you will never call kmalloc with __GFP_DIRECT_RECLAIM from the rescuer context, right?
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 48 lines · Michal Hocko
Quoted 47 lines · Oliver Neukum
Quoted 45 lines · Michal Hocko
Quoted 34 lines · Oliver Neukum
Quoted 26 lines · Michal Hocko
Quoted 18 lines · Oliver Neukum
Quoted 7 lines · Tejun Heo
Hello,
Quoted 2 lines
If any real IO depends on those devices then this is not sufficient and they need some form of guarantee for progress (aka mempool).
Oliver, Alan, what do you think? If USB itself can't operate without allocating memory during transactions, whatever USB storage drivers
It cannot. The IO must be described to the hardware with a data structure in memory.
Quoted 5 lines
are doing isn't all that meaningful. Can we proceed with the workqueue patches? Also, it could be that the only thing
GFP_NOIOandGFP_ATOMICare doing is increasing the chance of IO failures under memory pressure. Maybe it'd be a good idea to reconsider the approach?Quoted 6 lines
We had actual deadlocks with
GFP_KERNEL. It seems to me that the SCSI layer can deal with IO that cannot be completed due to a lack of memory at least somewhat, but a deadlock within a driver would obviously be deadly. So I don't think that mempools would remove the need forGFP_NOIOas there are places in usbcore we cannot enter the page laundering path from. They are an additional need.Quoted 6 lines
OK, I guess there is some misunderstanding here. I believe that Tejun wasn't arguing to drop
GFP_NOIO. It might be really needed for the dead lock avoidance. No question about that. The whole point is thatWQ_RECLAIMmight be completely pointless because a rescuer wouldn't help much if the work item would doGFP_NOIOand get stuck in the page allocator.Quoted 4 lines
But that can be a problem only if the items on the work queue are actually run and without
WQ_MEM_RECLAIMthat guarantee cannot be made. We can deal with failures of memory allocation. But the requests must actually terminate.I think you have missed my point. So let me ask differently. What is the difference between your work item not running at all or looping endlessly with
GFP_NOIOinside the page allocator? If that particular work item is necessary for the further progress then the system is screwed one way or another.
Quoted 6 lines
Quoted 3 lines
The key difference is that I could give the right parameters to the
kmalloc()call. If it doesn't run, I am surely screwed. Thus I conclude thatWQ_RECLAIMneeds to be set.Just to make sure I understand. So you will never call kmalloc with
__GFP_DIRECT_RECLAIMfrom the rescuer context, right?
Apparently if that is the requirement USB will have to define its own set of flags to use in such contexts. But still the calls as currently executed work. Taking away WQ_MEM_RECLAIM would create danger of introducing a regression. The issue with __GFP_DIRECT_RECLAIM already exists and can be fixed.
Regards
Oliver
Hello,
Quoted 5 lines · Oliver Neukum
Apparently if that is the requirement USB will have to define its own set of flags to use in such contexts. But still the calls as currently executed work. Taking away
WQ_MEM_RECLAIMwould create danger of introducing a regression. The issue with__GFP_DIRECT_RECLAIMalready exists and can be fixed.
Alright, let's go with WQ_MEM_RECLAIM then.
Thanks.
Signature · 1 line
tejun
Quoted 10 lines · Tejun Heo
Hello,
Quoted 5 lines · Oliver Neukum
Apparently if that is the requirement USB will have to define its own set of flags to use in such contexts. But still the calls as currently executed work. Taking away
WQ_MEM_RECLAIMwould create danger of introducing a regression. The issue with__GFP_DIRECT_RECLAIMalready exists and can be fixed.Alright, let's go with
WQ_MEM_RECLAIMthen.
Agreed, I would just add
/*
* TODO: make sure that no work item in the rescuer can block on an
* allocation (so no __GF_DIRECT_RECLAIM)
*/
to all work item functions.
Signature · 2 lines
Michal Hocko SUSE Labs