[lkml]   [2004]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [parisc-linux] rmap: parisc __flush_dcache_page
    On Thu, 2004-04-08 at 13:18, Andrea Arcangeli wrote:
    > it enterely depends on the workload. On a desktop machine there may be
    > only some hundred entries in those lists at maximum with glibc being the
    > biggest offender:
    > cat /proc/*/maps | grep | wc -l
    > with shared memory on some server there can be easily several thousand
    > entries for some inode even on 64bit, but a timeslice was probably
    > exaggerated (the timeslice was for the walking of the ptes in each
    > mapping too, I don't think you need to look at every pte).

    So you're worried about our code? OK, if you look, you'll see we only
    have to flush one address in the mmap_shared list, (which is usually the
    long list).

    I'd constructed it on the predicate that flushing a non-current space is
    more expensive than finding a current one, but I can alter it to flush
    the first vma it comes to with a present translation.

    The mmap list is usually empty. We only excite that case for multiple
    private mappings of a file which for some reason gets updated.

    I'd be very surprised if flush_dcache_page executes more than a few
    hundred instructions all told...that's certainly nowhere close to a


    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 14:02    [W:0.025 / U:10.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site