lkml.org 
[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 2/2] mm: compaction: Minimise the time IRQs are disabled while isolating pages for migration
    From
    On Wed, Mar 2, 2011 at 7:34 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
    > On Wed, 2 Mar 2011 07:22:33 +0900
    > Minchan Kim <minchan.kim@gmail.com> wrote:
    >
    >> On Wed, Mar 2, 2011 at 1:19 AM, Andrea Arcangeli <aarcange@redhat.com> wrote:
    >> > On Wed, Mar 02, 2011 at 12:35:58AM +0900, Minchan Kim wrote:
    >> >> On Tue, Mar 01, 2011 at 01:49:25PM +0900, KAMEZAWA Hiroyuki wrote:
    >> >> > On Tue, 1 Mar 2011 13:11:46 +0900
    >> >> > Minchan Kim <minchan.kim@gmail.com> wrote:
    >> >> >
    >>
    >> ...
    >>
    >> > pages freed from irq shouldn't be PageLRU.
    >>
    >> Hmm..
    >> As looking code, it seems to be no problem and I didn't see the any
    >> comment about such rule. It should have been written down in
    >> __page_cache_release.
    >> Just out of curiosity.
    >> What kinds of problem happen if we release lru page in irq context?
    >
    > put_page() from irq context has been permissible for ten years.  I
    > expect there are a number of sites which do this (via subtle code
    > paths, often).  It might get messy.
    >
    >> >
    >> > deferring freeing to workqueue doesn't look ok. firewall loads runs
    >> > only from irq and this will cause some more work and a delay in the
    >> > freeing. I doubt it's worhwhile especially for the lru_lock.
    >> >
    >>
    >> As you said, if it is for decreasing lock contention in SMP to deliver
    >> overall better performance, maybe we need to check again how much it
    >> helps.
    >> If it doesn't help much, could we remove irq_save/restore of lru_lock?
    >> Do you know any benchmark to prove it had a benefit at that time or
    >> any thread discussing about that in lkml?
    >
    >
    > : commit b10a82b195d63575958872de5721008b0e9bef2d
    > : Author: akpm <akpm>
    > : Date:   Thu Aug 15 18:21:05 2002 +0000
    > :
    > :     [PATCH] make pagemap_lru_lock irq-safe
    > :
    > :     It is expensive for a CPU to take an interrupt while holding the page
    > :     LRU lock, because other CPUs will pile up on the lock while the
    > :     interrupt runs.
    > :
    > :     Disabling interrupts while holding the lock reduces contention by an
    > :     additional 30% on 4-way.  This is when the only source of interrupts is
    > :     disk completion.  The improvement will be higher with more CPUs and it
    > :     will be higher if there is networking happening.
    > :
    > :     The maximum hold time of this lock is 17 microseconds on 500 MHx PIII,
    > :     which is well inside the kernel's maximum interrupt latency (which was
    > :     100 usecs when I last looked, a year ago).
    > :
    > :     This optimisation is not needed on uniprocessor, but the patch disables
    > :     IRQs while holding pagemap_lru_lock anyway, so it becomes an irq-safe
    > :     spinlock, and pages can be moved from the LRU in interrupt context.
    > :
    > :     pagemap_lru_lock has been renamed to _pagemap_lru_lock to pick up any
    > :     missed uses, and to reliably break any out-of-tree patches which may be
    > :     using the old semantics.
    > :
    > :     BKrev: 3d5bf1110yfdAAur4xqJfiLBDJ2Cqw
    >
    >
    > Ancient stuff, and not a lot of detail.  But I did measure it.  I
    > measured everything ;) And, as mentioned, I'd expect that the
    > contention problems would worsen on higher CPU machines and higher
    > interrupt frequencies.

    Thanks for giving the important information.

    >
    > I expect we could eliminate the irqsave requirement from
    > rotate_reclaimable_page() simply by switching to a trylock.  Some pages
    > will end up at the wrong end of the LRU but the effects may be
    > negligible.  Or perhaps they may not - disk seeks are costly.
    >
    >

    Releasing 14 pages should not have much cost about interrupt latency
    and It's a general concept we have been used. If it really has a
    problem, I think it would be better to reduce PAGEVEC_SIZE rather than
    fixing the rotate_reclaimable_page.




    --
    Kind regards,
    Minchan Kim
    --
    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: 2011-03-02 00:07    [W:0.030 / U:59.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site