On Thursday 14 March 2002 12:06, David Brownell wrote:
> > > > Agreed. But we can ask the HCD how much to reserve allocating the
> > > > urb.
> > >
> > > And that would work ... how? Remember it's a multi-dimensional
> > > problem. ....
> > > That essential information is unavailable when the URB is allocated.
> > > It's known for the first time when the URB is submitted.
> >
> > Could we add a pointer to a reserve page to the urb structure ?
> > Can you give an upper bound on the amount of memory needed ?
>
> That's all a function of the URB that's submitted ... including all the
> factors I mentioned, and a few more. A given URB clearly needs
> a certain number of TDs; a different URB can need more (or less)
> even if it's the same size (and type) transfer.
But surely there must be some upper boundary of memory usage ?
> > Unfortunately, to be safe in the writeout path, no memory at all must be
> > allocated
>
> That sounds like the problem is rather overconstrained.
> Surely there's a more reasonable characterization of the
> issue than that ...
I am afraid not.
> And page writes to remote disks (NFS etc) surely ought to
> work too, such as for mmapped application data (or even
> swapfiles). Network I/O tends to allocate memory, yes?
> Paging over NFS worked since NFS first existed.
Because nfs can deal with network packets being lost.
Whether this happens on the wire or due to a lack of memory
doesn't matter.
Network drivers usually use GFP_ATOMIC. Thus the atomic
pool of pages is used. Presumably the atomic pool is used
dynamically thus after a few retries it's highly likely that
a request will go through.
This is not the case for block devices. Either it works
or it doesn't. You can defer a scsi command, but only
before you queue it.
Incidentally, I am not sure whether nfs over ppp is safe.
Is it possible that the ppp counterpart insists on
reauthentification just as we need to page ?
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
