On 03/04/2015 02:33 AM, Dave Chinner wrote:
On Tue, Mar 03, 2015 at 10:13:04AM +0100, Vlastimil Babka wrote:
Preallocated reserves do not allow for unbound demand paging of
reclaimable objects within reserved allocation contexts.
OK I think I get the point now.
So, lots of the concerns by me and others were about the wasted memory due to
reservations, and increased pressure on the rest of the system. I was thinking,
are you able, at the beginning of the transaction (for this purposes, I think of
transaction as the work that starts with the memory reservation, then it cannot
rollback and relies on the reserves, until it commits and frees the memory),
determine whether the transaction cannot be blocked in its progress by any other
transaction, and the only thing that would block it would be inability to
allocate memory during its course?
No. e.g. any transaction that requires allocation or freeing of an
inode or extent can get stuck behind any other transaction that is
allocating/freeing and inode/extent. And this will happen when
holding inode locks, which means other transactions on that inode
will then get stuck on the inode lock, and so on. Blocking
dependencies within transactions are everywhere and cannot be
avoided.
Hm, I see. I thought that perhaps to avoid deadlocks between
transactions (which you already have to do somehow), either the
dependencies have to be structured in a way that there's always some
transaction that can't block on others. Or you have a way to detect
potential deadlocks before they happen, and stall somebody who tries to
lock. Both should (at least theoretically) mean that you would be able
to point to such transaction, although I can imagine the cost of being
able to do that could be prohibitive.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>