lkml.org 
[lkml]   [2002]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.4.19pre1aa1
    Andrea Arcangeli wrote:
    >
    >
    > depends what you're doing, if you do `cp /dev/zero .` and the fs is
    > lucky enough to have free contigous space I definitely can see the
    > improvement of highlevel merging, but that's not always what you're
    > doing with the fs, for example that's not the case for kernel compiles
    > and small files where you'll be always fragmented and where the bio will
    > at max hold 4k and you keep rewriting into cache.

    Cache effects. We touch the buffers at prepare_write. We touch them
    again at commit_write(). And at writeout time. And at page reclaim
    time. I think it's this general white-noise cost which is causing
    the funny profiles which I'm seeing. (For example, with no-buffers,
    the cost of the IDE driver setup and interrupt handler has nosedived).

    > The times you enter
    > get_block you enter in a fs lock, rather than staying at the per-page
    > lock, it's not additional locking, the bh on the pagecahce doesn't need
    > any additional locking.

    For writes, we have the lru list insertion, and the hashtable lock (twice).

    > So for a kernel compile the current situation is
    > an obvious advantage in performance and scalability (fs code definitely
    > doesn't scale at the moment).

    mm.. Delayed allocation means that the short-lived files never get
    a disk mapping at all.

    And yes, if all files are 100% fragmented then the BIO aggregation
    doesn't help as much.

    > But ok, globally it will be probably better to drop the bh since we have
    > to work on the bio anyways somehow and so at the very least we don't
    > want to be slowed down from the bio logic in the physically contigous
    > pagecache flood case.
    >
    > I just meant the bh isn't totally pointless and it could be shrunk as
    > Arjan said in a private email.

    bh represents a disk block. It's a wrapper around a section of the
    block device's pagecache pages. We'll always need a representation
    of disk blocks. For filesystem metadata.

    -
    -
    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/

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