On Wed, 2 Mar 2011 07:22:33 +0900 Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > On Wed, Mar 2, 2011 at 1:19 AM, Andrea Arcangeli <aarcange@xxxxxxxxxx> 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@xxxxxxxxx> 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. 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>