On Mon, Aug 5, 2024 at 4:26 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Mon, Aug 05, 2024 at 04:21:06PM +0800, Jason Wang wrote: > > Barry said [1]: > > > > """ > > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because > > __GFP_NOFAIL without direct reclamation may just result in a busy > > loop within non-sleepable contexts. > > ""“ > > > > Unfortuantely, we do that under read lock. A possible way to fix that > > is to move the pages allocation out of the lock into the caller, but > > having to allocate a huge number of pages and auxiliary page array > > seems to be problematic as well per Tetsuon [2]: > > > > """ > > You should implement proper error handling instead of using > > __GFP_NOFAIL if count can become large. > > """ > > > > So I choose another way, which does not release kernel bounce pages > > when user tries to register usersapce bounce pages. Then we don't need > > userspace > > > to do allocation in the path which is not expected to be fail (e.g in > > the release). We pay this for more memory usage but further > > what does "we pay this for more memory usage" mean? > Do you mean "we pay for this by using more memory"? Yes. > How much more? Depends on the workload, but basically, it's just the maximum size of bounce buffer: Default size 64M #define VDUSE_BOUNCE_SIZE (64 * 1024 * 1024) Maximum 1G: #define VDUSE_MAX_BOUNCE_SIZE (1024 * 1024 * 1024) Thanks
