On Wed, 05 Jan 2011 16:00:09 +0800
Shaohua Li <shaohua.li@xxxxxxxxx> wrote:
> The zone->lru_lock is heavily contented in workload where activate_page()
> is frequently used. We could do batch activate_page() to reduce the lock
> contention. The batched pages will be added into zone list when the pool
> is full or page reclaim is trying to drain them.
>
> For example, in a 4 socket 64 CPU system, create a sparse file and 64 processes,
> processes shared map to the file. Each process read access the whole file and
> then exit. The process exit will do unmap_vmas() and cause a lot of
> activate_page() call. In such workload, we saw about 58% total time reduction
> with below patch. Other workloads with a lot of activate_page also benefits a
> lot too.
There still isn't much info about the performance benefit here. Which
is a bit of a problem when the patch's sole purpose is to provide
performance benefit!
So, much more complete performance testing results would help here.
And it's not just the "it sped up an obscure corner-case workload by
N%". How much impact (postive or negative) does the patch have on
other workloads?
And while you're doing the performance testing, please test this
version too:
--- a/mm/swap.c~a
+++ a/mm/swap.c
@@ -261,6 +261,10 @@ void activate_page(struct page *page)
{
struct zone *zone = page_zone(page);
+ /* Quick, racy check to avoid taking the lock */
+ if (PageActive(page) || !PageLRU(page) || PageUnevictable(page))
+ return;
+
spin_lock_irq(&zone->lru_lock);
if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
int file = page_is_file_cache(page);
_
--
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 policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>