All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lin Ming <ming.m.lin@intel.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
	mingo <mingo@elte.hu>, Gregory Haskins <ghaskins@novell.com>
Subject: Re: oltp ~10% regression with 2.6.27-rc5 on stoakley machine
Date: Thu, 04 Sep 2008 20:12:08 +0800	[thread overview]
Message-ID: <1220530328.12161.29.camel@minggr> (raw)
In-Reply-To: <1220526360.8609.213.camel@twins>


> > > Thats bizarre... that just indicates the better clock, which should give
> > > better (read fairer) scheduling hurts your workload.
> > > 
> > > Is there anything I can run to see if we can fix the scheduler perhaps?
> > 
> > I observed schedstats of sysbench, there's more
> > "nr_failed_migrations_hot"
> > 
> > 2.6.27-rc4: se.nr_failed_migrations_hot 11
> > 2.6.27-rc5: se.nr_failed_migrations_hot 95
> > 
> > task migration failed because of task_hot, the system is un-balanced?
> 
> Ah, that makes sense, a more accurate clock could indeed make more tasks
> hot.
> 
> Can you try fiddling with: /proc/sys/kernel/sched_migration_cost ?

sched_migration_cost		regression
----------------------          -------------
50000                           ~6%
0				~8%
500000 (default)		~10%
5000000                         ~14%
-1				~19%
			
> 
> Also, we used to have some auto-tuning in there, which dissapeared some
> time ago, gregory brought it back to live recently, perhaps he likes to
> share? :-)
> 


  reply	other threads:[~2008-09-04 12:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-04  8:51 oltp ~10% regression with 2.6.27-rc5 on stoakley machine Lin Ming
2008-09-04  9:03 ` Peter Zijlstra
2008-09-04 10:52   ` Lin Ming
2008-09-04 11:06     ` Peter Zijlstra
2008-09-04 12:12       ` Lin Ming [this message]
2008-09-04 12:26         ` Peter Zijlstra
2008-09-04 12:42           ` Lin Ming
2008-09-04 13:50       ` Gregory Haskins
2008-09-04 13:50         ` [PATCH 1/4] revert "sched: sched_cacheflush is now unused" Gregory Haskins
2008-09-04 13:50         ` [PATCH 2/4] Revert "[PATCH] sched: remove cache_hot_time" Gregory Haskins
2008-09-04 13:50         ` [PATCH 3/4] Revert "sched: zap the migration init / cache-hot balancing code" Gregory Haskins
2008-09-04 13:50         ` [PATCH 4/4] sched: make task_hot() once again use sd->cache_hot_time Gregory Haskins
2008-09-04 11:09     ` oltp ~10% regression with 2.6.27-rc5 on stoakley machine Ingo Molnar
2008-09-04 11:30       ` Lin Ming
2008-09-04 11:35         ` Ingo Molnar
2008-09-04 12:19           ` Lin Ming
2008-09-05  1:26   ` Lin Ming
2008-09-20 21:38 ` Peter Zijlstra
2008-09-26  2:00   ` Lin Ming
  -- strict thread matches above, loose matches on Subject: below --
2008-09-04  7:06 Lin Ming

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=1220530328.12161.29.camel@minggr \
    --to=ming.m.lin@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ghaskins@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=yanmin_zhang@linux.intel.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.