All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitri Sivanich <sivanich@sgi.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org,
	lse-tech <lse-tech@lists.sourceforge.net>,
	linux-mm@kvack.org
Subject: Re: [PATCH]: Option to run cache reap in thread mode
Date: Wed, 16 Jun 2004 13:02:08 -0500	[thread overview]
Message-ID: <20040616180208.GD6069@sgi.com> (raw)
In-Reply-To: <40D08225.6060900@colorfullife.com>

On Wed, Jun 16, 2004 at 07:23:49PM +0200, Manfred Spraul wrote:
> Dimitri wrote:
> 
> >In the process of testing per/cpu interrupt response times and CPU 
> >availability,
> >I've found that running cache_reap() as a timer as is done currently 
> >results
> >in some fairly long CPU holdoffs.
> >
> What is fairly long?
Into the 100's of usec.  I consider anything over 30 usec too long.
I've seen this take longer than 30usec on a small (8p) system.

> If cache_reap() is slow than the caches are too large.
> Could you limit cachep->free_limit and check if that helps? It's right 
> now scaled by num_online_cpus() - that's probably too much. It's 
> unlikely that all 500 cpus will try to refill their cpu arrays at the 
> same time. Something like a logarithmic increase should be sufficient.

I haven't tried this yet, but I'm even seeing this on 4 cpu systems.

> Do you use the default batchcount values or have you increased the values?

Default.

> I think the sgi ia64 system do not work with slab debugging, but please 
> check that debugging is off. Debug enabled is slow.

# CONFIG_DEBUG_SLAB is not set

> 
> --
>    Manfred

Dimitri Sivanich <sivanich@sgi.com>

WARNING: multiple messages have this Message-ID (diff)
From: Dimitri Sivanich <sivanich@sgi.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org,
	lse-tech <lse-tech@lists.sourceforge.net>,
	linux-mm@kvack.org
Subject: Re: [PATCH]: Option to run cache reap in thread mode
Date: Wed, 16 Jun 2004 13:02:08 -0500	[thread overview]
Message-ID: <20040616180208.GD6069@sgi.com> (raw)
In-Reply-To: <40D08225.6060900@colorfullife.com>

On Wed, Jun 16, 2004 at 07:23:49PM +0200, Manfred Spraul wrote:
> Dimitri wrote:
> 
> >In the process of testing per/cpu interrupt response times and CPU 
> >availability,
> >I've found that running cache_reap() as a timer as is done currently 
> >results
> >in some fairly long CPU holdoffs.
> >
> What is fairly long?
Into the 100's of usec.  I consider anything over 30 usec too long.
I've seen this take longer than 30usec on a small (8p) system.

> If cache_reap() is slow than the caches are too large.
> Could you limit cachep->free_limit and check if that helps? It's right 
> now scaled by num_online_cpus() - that's probably too much. It's 
> unlikely that all 500 cpus will try to refill their cpu arrays at the 
> same time. Something like a logarithmic increase should be sufficient.

I haven't tried this yet, but I'm even seeing this on 4 cpu systems.

> Do you use the default batchcount values or have you increased the values?

Default.

> I think the sgi ia64 system do not work with slab debugging, but please 
> check that debugging is off. Debug enabled is slow.

# CONFIG_DEBUG_SLAB is not set

> 
> --
>    Manfred

Dimitri Sivanich <sivanich@sgi.com>
--
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-06-16 18:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-16 17:23 [PATCH]: Option to run cache reap in thread mode Manfred Spraul
2004-06-16 18:02 ` Dimitri Sivanich [this message]
2004-06-16 18:02   ` Dimitri Sivanich
2004-06-16 18:58   ` Manfred Spraul
2004-06-16 18:58     ` Manfred Spraul
2004-06-17 13:10     ` Dimitri Sivanich
2004-06-17 13:10       ` Dimitri Sivanich
2004-06-18  4:40       ` Andrew Morton
2004-06-18  4:40         ` Andrew Morton
2004-06-18 14:33         ` Dimitri Sivanich
2004-06-18 14:33           ` Dimitri Sivanich
2004-06-18 20:40           ` Andrew Morton
2004-06-18 20:40             ` Andrew Morton
2004-06-18 21:04             ` Manfred Spraul
2004-06-18 21:04               ` Manfred Spraul
2004-06-18 21:44               ` Dimitri Sivanich
2004-06-18 21:44                 ` Dimitri Sivanich
2004-06-18 22:03               ` Andrew Morton
2004-06-18 22:03                 ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2004-06-16 16:43 Mark_H_Johnson
2004-06-16 16:43 ` Mark_H_Johnson
     [not found] <27JKg-4ht-11@gated-at.bofh.it>
2004-06-16 16:22 ` Andi Kleen
2004-06-16 18:16   ` Dimitri Sivanich
2004-06-16 18:16     ` Dimitri Sivanich
2004-06-16 14:24 Dimitri Sivanich
2004-06-16 14:24 ` Dimitri Sivanich
2004-06-16 15:29 ` Christoph Hellwig
2004-06-16 15:29   ` Christoph Hellwig
2004-06-16 16:03   ` Dimitri Sivanich
2004-06-16 16:03     ` Dimitri Sivanich
2004-06-16 16:07     ` Christoph Hellwig
2004-06-16 16:07       ` Christoph Hellwig
2004-06-16 16:25       ` Jesse Barnes
2004-06-16 16:25         ` Jesse Barnes
2004-06-16 16:51         ` Dimitri Sivanich
2004-06-16 16:51           ` Dimitri Sivanich
2004-06-16 16:46 ` Lori Gilbertson
2004-06-16 16:46   ` Lori Gilbertson
2004-06-16 16:53   ` Christoph Hellwig
2004-06-16 16:53     ` Christoph Hellwig
2004-06-16 21:30 ` Andrew Morton
2004-06-16 21:30   ` Andrew Morton

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=20040616180208.GD6069@sgi.com \
    --to=sivanich@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=manfred@colorfullife.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.