All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Nikita Danilov <nikita@clusterfs.com>,
	Linux Kernel Mailing List <Linux-Kernel@vger.kernel.org>,
	Andrew Morton <AKPM@Osdl.ORG>,
	Linux MM Mailing List <linux-mm@kvack.org>
Subject: Re: [PATCH]: 1/4 batch mark_page_accessed()
Date: Sat, 27 Nov 2004 11:37:17 +1100	[thread overview]
Message-ID: <41A7CC3D.9030405@yahoo.com.au> (raw)
In-Reply-To: <20041126185833.GA7740@logos.cnet>

Marcelo Tosatti wrote:
> On Sun, Nov 21, 2004 at 06:44:04PM +0300, Nikita Danilov wrote:
> 
>>Batch mark_page_accessed() (a la lru_cache_add() and lru_cache_add_active()):
>>page to be marked accessed is placed into per-cpu pagevec
>>(page_accessed_pvec). When pagevec is filled up, all pages are processed in a
>>batch.
>>
>>This is supposed to decrease contention on zone->lru_lock.
> 
> 
> Here are the STP 8way results:
> 
> 8way:
> 

...

> kernbench 
> 
> Decreases performance significantly (on -j4 more notably), probably due to 
> the additional atomic operations as noted by Andrew:
> 
> kernel: nikita-b2                               kernel: patch-2.6.10-rc2
> Host: stp8-002                                  Host: stp8-003
> 

...

> 
> Average Half Load -j 4 Run:                     Average Half Load -j 4 Run:
> Elapsed Time 274.916                            Elapsed Time 245.026
> User Time 833.63                                User Time 832.34
> System Time 73.704                              System Time 73.41
> Percent CPU 335.8                               Percent CPU 373.6
> Context Switches 12984.8                        Context Switches 13427.4
> Sleeps 21459.2                                  Sleeps 21642

Do you think looks like it may be a CPU scheduling or disk/fs artifact?
Neither user nor system time are significantly worse, while the vanilla
kernel is using a lot more of the CPUs' power (ie waiting for IO less,
or becoming idle less often due to CPU scheduler balancing).

Aside: under-load conditions like this is actually something where the
CPU scheduler doesn't do brilliantly at currently. I attribute this to
probably most "performance tests" loading it up as much as possible.
I am (on and off) looking at improving performance in these conditions,
and am making some inroads.

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Nikita Danilov <nikita@clusterfs.com>,
	Linux Kernel Mailing List <Linux-Kernel@vger.kernel.org>,
	Andrew Morton <AKPM@Osdl.ORG>,
	Linux MM Mailing List <linux-mm@kvack.org>
Subject: Re: [PATCH]: 1/4 batch mark_page_accessed()
Date: Sat, 27 Nov 2004 11:37:17 +1100	[thread overview]
Message-ID: <41A7CC3D.9030405@yahoo.com.au> (raw)
In-Reply-To: <20041126185833.GA7740@logos.cnet>

Marcelo Tosatti wrote:
> On Sun, Nov 21, 2004 at 06:44:04PM +0300, Nikita Danilov wrote:
> 
>>Batch mark_page_accessed() (a la lru_cache_add() and lru_cache_add_active()):
>>page to be marked accessed is placed into per-cpu pagevec
>>(page_accessed_pvec). When pagevec is filled up, all pages are processed in a
>>batch.
>>
>>This is supposed to decrease contention on zone->lru_lock.
> 
> 
> Here are the STP 8way results:
> 
> 8way:
> 

...

> kernbench 
> 
> Decreases performance significantly (on -j4 more notably), probably due to 
> the additional atomic operations as noted by Andrew:
> 
> kernel: nikita-b2                               kernel: patch-2.6.10-rc2
> Host: stp8-002                                  Host: stp8-003
> 

...

> 
> Average Half Load -j 4 Run:                     Average Half Load -j 4 Run:
> Elapsed Time 274.916                            Elapsed Time 245.026
> User Time 833.63                                User Time 832.34
> System Time 73.704                              System Time 73.41
> Percent CPU 335.8                               Percent CPU 373.6
> Context Switches 12984.8                        Context Switches 13427.4
> Sleeps 21459.2                                  Sleeps 21642

Do you think looks like it may be a CPU scheduling or disk/fs artifact?
Neither user nor system time are significantly worse, while the vanilla
kernel is using a lot more of the CPUs' power (ie waiting for IO less,
or becoming idle less often due to CPU scheduler balancing).

Aside: under-load conditions like this is actually something where the
CPU scheduler doesn't do brilliantly at currently. I attribute this to
probably most "performance tests" loading it up as much as possible.
I am (on and off) looking at improving performance in these conditions,
and am making some inroads.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-11-27  0:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-21 15:44 [PATCH]: 1/4 batch mark_page_accessed() Nikita Danilov
2004-11-21 15:44 ` Nikita Danilov
2004-11-21 21:12 ` Andrew Morton
2004-11-21 21:12   ` Andrew Morton
2004-11-24 10:40   ` Marcelo Tosatti
2004-11-24 10:40     ` Marcelo Tosatti
2004-11-24 16:32 ` Marcelo Tosatti
2004-11-24 16:32   ` Marcelo Tosatti
2004-11-24 21:53   ` Nikita Danilov
2004-11-24 21:53     ` Nikita Danilov
2004-11-26 18:58 ` Marcelo Tosatti
2004-11-26 18:58   ` Marcelo Tosatti
2004-11-27  0:37   ` Nick Piggin [this message]
2004-11-27  0:37     ` Nick Piggin
2004-11-30 16:29     ` Marcelo Tosatti
2004-11-30 16:29       ` Marcelo Tosatti
2004-12-01  1:33       ` Andrew Morton
2004-12-01  1:33         ` Andrew Morton
2004-11-30 22:57         ` Marcelo Tosatti
2004-11-30 22:57           ` Marcelo Tosatti
2004-12-01 12:23         ` Nikita Danilov
2004-12-01 12:23           ` Nikita Danilov
2004-12-01 18:58           ` Marcelo Tosatti
2004-12-01 18:58             ` Marcelo Tosatti
2004-12-02  1:59             ` Andrew Morton
2004-12-02  1:59               ` Andrew Morton
2004-11-27 10:41   ` Nikita Danilov
2004-11-27 10:41     ` Nikita Danilov
2004-11-27  8:19     ` Marcelo Tosatti
2004-11-27  8:19       ` Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41A7CC3D.9030405@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=AKPM@Osdl.ORG \
    --cc=Linux-Kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=nikita@clusterfs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.