Nick Piggin wrote: > > Suppose the systems has two pages to be written. The first must > > _reserve_ 40 pages of scratch space just in case the operation will > > need them. If the second page write is initiated concurrently with > > the first, the second must reserve another 40 pages concurrently. > > > > If 10 page writes are concurrent, that's 400 pages of scratch space > > needed in reserve... > > You only need to guarantee forward progress, so you would reserve > 40 pages up front for the entire machine (some mempools have more > memory than strictly needed to improve performance, so you could > toy with that, but let's just describe the baseline). > > So allocations happen as normal, except when an allocation fails, > then the task which fails the allocation is given access to this > reserve memory, any other task requiring reserve will then block. > > Now the reserve provides enough pages to guarantee forward progress, > so that one task is going to be able to proceed and eventually its > pages will become freeable and can be returned to the reserve. Once > the writeout has finished, the reserve will become available to > other tasks. > > So this way you only have to reserve enough to write out 1 page, > and you only start blocking things when their memory allocations > wolud have failed *anyway*. And you guarantee forward progress. Ah. *light bulb* In the writing tasks, memory allocation is forbidden, but blocking is allowed. That's what I was missing :-) Forward progress marches on. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
