[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, Apr 08, 2004 at 01:28:17PM -0500, James Bottomley wrote:
    > 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).

    if you need to flush just one address, the prio-tree may give you an
    huge boost, overall flush_dcache_page should become pretty quick in most

    > 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
    > timeslice.

    What you miss is that the problem is not in flush_dcache_page, the
    problem is that the _other_ users of the prio-tree may take as long as a
    timeslice. So it's the _other_ user that you've no control about (i.e.
    truncate) that may take timeslices with irq disabled.

    But I've an fairly optimal solution for you, you should make it a
    read_write spinlock, with the readers not disabling interrupts, and the
    writer disabling interrupts, the writer of the prio-tree will not take a
    timeslice, the readers instead will take a timeslice, but since they're
    readers and you've only to read in the flush_dcache_page irq context,
    you don't need to disable irqs for the readers. I don't have better
    solutions than this one at the moment (yeah there's the rcu reading of
    the prio-tree but I'd leave it for later...)
    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.036 / U:18.948 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site