Re: ext3 allocate-with-reservation latencies

From: Stephen C. Tweedie (sct_at_redhat.com)
Date: 04/11/05

  • Next message: Humberto Massa: "Re: non-free firmware in kernel modules, aggregation and unclear copyright notice." 
    To: Mingming Cao <cmm@us.ibm.com>
Date:	Mon, 11 Apr 2005 12:48:09 +0100

    Hi,

    On Fri, 2005-04-08 at 19:10, Mingming Cao wrote:

    > > It still needs to be done under locking to prevent us from expanding
    > > over the next window, though. And having to take and drop a spinlock a
    > > dozen times or more just to find out that there are no usable free
    > > blocks in the current block group is still expensive, even if we're not
    > > actually fully unlinking the window each time.

    > Isn't this a rare case? The whole group is relatively full and the free
    > bits are all reserved by other files.

    Well, that's not much different from the case where there _are_ usable
    bits but they are all near the end of the bitmap. And that's common
    enough as you fill up a block group with small files, for example. Once
    the bg becomes nearly full, new file opens-for-write will still try to
    allocate in that bg (because that's where the inode was allocated), but
    as it's a new fd we have no prior knowledge of _where_ in the bh to
    allocate, and we'll have to walk it to the end to find any free space.
    This is the access pattern I'd expect of (for example) "tar xvjf
    linux-2.6.12.tar.bz2", not exactly a rare case.

    > Probably we should avoid trying
    > to make reservation in this block group at the first place

    Not in this case, because it's the "home" of the file in question, and
    skipping to another bg would just leave useful space empty --- and that
    leads to fragmentation.

    > You are proposing that we hold the read lock first, do the window search
    > and bitmap scan, then once we confirm there is free bit in the candidate
    > window, we grab the write lock and update the tree?

    No, I'm suggesting that if we need the write lock for tree updates, we
    may still be able to get away with just a read lock when updating an
    individual window. If all we're doing is winding the window forwards a
    bit, that's not actually changing the structure of the tree.

    > However I am still worried that the rw lock will allow concurrent files
    > trying to lock the same window at the same time.

    Adding a new window will need the write lock, always. But with the read
    lock, we can still check the neighbouring windows (the structure is
    pinned so those remain valid), so advancing a window with just that lock
    can still be done without risking overlapping the next window.

    --Stephen

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Humberto Massa: "Re: non-free firmware in kernel modules, aggregation and unclear copyright notice."

    Relevant Pages

    • Re: ext3 allocate-with-reservation latencies
      ... >> tree, and using read lock for that should help reduce the latency. ... So it could set the reservation window size large enough ... But I wonder if the latency saw by Lee belongs to this worst-case: ...
      (Linux-Kernel)
    • Re: ext3 allocate-with-reservation latencies
      ... > enough as you fill up a block group with small files, ... probably try to skip the block groups without enough usable free blocks ... > No, I'm suggesting that if we need the write lock for tree updates, we ... > individual window. ...
      (Linux-Kernel)
    • Re: ext3 allocate-with-reservation latencies
      ... > what I was suggesting is, if allocation from the home group failed and ... > probably try to skip the block groups without enough usable free blocks ... and using read lock for that should help reduce the latency. ... window, and that's going to have to wait for us to finish finding a free ...
      (Linux-Kernel)
    • Re: Isolation level question
      ... But you are getting an EXCLUSIVE lock when update the row where nunber = 1. ... > first window I run: ... > set transaction isolation level read uncommitted ... > In the second window, ...
      (microsoft.public.sqlserver.programming)
    • RE: synchronizing domain user Local cached credentials with domain (VP
      ... locally cached credentials are out of sync with domain credentials. ... For the technical savvy will lock their screen and logon on ... change (script the detection of the Window bubble, ...
      (microsoft.public.windowsxp.security_admin)