Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, Alan.

On Wed, Jul 27, 2016 at 04:45:19PM -0400, Alan Stern wrote:
> > 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.
> 
> > 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.

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.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux