[lkml]   [2002]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.4.19pre3aa2
    On Sat, Mar 16, 2002 at 02:10:27PM +0200, Jari Ruusu wrote:
    > Andrea Arcangeli wrote:
    > > Nevertheless as Jens said the infinite-loop-allocation in the
    > > ->make_request_fn path are deadlock prone at the moment, not because
    > > they sleeps but because they need a reserved mempool to guarantee
    > > operations can go ahead slowly without deadlocks even if dynamic
    > > allocation fails, but this is not a very pratical problem, it's very
    > > unlikely to deadlock there (it's not worse than the other infinite loop
    > > in getblk() that affects not just loop).
    > Unlikely to deadlock for normal filesystems, but swap on encrypted loop is a
    > different case.

    Not really much different, it's no different than other paths like
    getblk (when you swap on top of the fs) and brw_page (OTOH we have a
    little reserved shared pool for the async bh needed by brw_page but it's not
    math accurate first of all because it's shared for the other pagecache
    I/O too), it just increases a little the mem pressure when there's
    a transfer function involved and the translation cannot be done in
    place, but I obviously agree that such loop deadlock needs fixing
    reagardless if it's easy to reproduce it or not :). Infact I think I
    mentioned such deadlock in the past too.

    > Deadlock free operation is exactly why my prealloc loop patch is needed.
    > Beyond initial preallocating that is done at losetup time, it does not
    > allocate anything from kernel memory pools, but effectively recycles its
    > private per loop device preallocated memory. Encrypted swap needs that, and
    > normal device backed loop file systems are also happy with deadlock free and
    > VM stress free operation.

    Yes, thanks.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:24    [W:0.024 / U:2.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site