On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote: > And you probably couldn't use GPU memory for this purpose because (I > assume) the USB host controller wouldn't be able to access it via DMA.
I guess that depends a bit; on my particular system, I'm using an Intel GPU, so memory is shared. But I assume you can't do this if the memory is dedicated and just mapped up from a dedicated GPU. > Incidentally, I wonder how well this patch really does fix your > problem. What happens if you run the old program until it fails with > the "unable to allocate memory" error and then try running the new > program? I suspect the new program will also fail under those > circumstances. The only advantage it has is that if the initial > allocations succeed then you don't have to worry about later > allocations failing, because the buffer memory is allocated only once. You are right in that it doesn't solve at all the problem “can't allocate memory on startup”, but that's not the problem I have at all. So it really does solve my problem, but it does not solve all other related problems. Incidentally, once it's really bad (without the patch), I can usually run for a few frames before it starts failing again, so I would assume that the result of the experiment you're proposing would actually be “it works well”. Seemingly the memory fragmentation (or whatever it is) just increases the probability of the allocation failing by a lot, it doesn't move it to 100%. /* Steinar */ -- Homepage: https://www.sesse.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
