LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Willy Tarreau <w@1wt.eu>, Ray Lee <ray-lk@madrabbit.org>,
	Ingo Molnar <mingo@elte.hu>,
	"LKML," <linux-kernel@vger.kernel.org>
Subject: Re: Poor PostgreSQL scaling on Linux 2.6.25-rc5 (vs 2.6.22)
Date: Mon, 17 Mar 2008 10:28:04 +0100	[thread overview]
Message-ID: <1205746084.8514.301.camel@twins> (raw)
In-Reply-To: <200803171954.01315.nickpiggin@yahoo.com.au>


Nick,

We do grow the period as the load increases, and this keeps the slice
constant - although it might not be big enough for your taste (but its
tunable)

Short running tasks will indeed be very likely to be run quickly after
wakeup because wakeup's are placed left in the tree. (and when using
sleeper fairness, can get up to a whole slice bonus).

Interactivity is all about generating a scheduling pattern that is easy
on the human brain - that means predictable and preferably with lags <
40ms - as long as the interval is predictable the human brain will patch
up a lot, once it becomes erratic all is out the window. (human
perception of lags is in the 10ms range, but up to 40ms seems to do
acceptable patch up as long as its predictable).

Due to current desktop bloat, its important cpu bound tasks are treated
well too. Take for instance scrolling firefox - that utterly consumes
the fastest cpus, still people expect a smooth experience. By ensuring
the scheduler behaviour degrades in a predicatable fashion, and trying
to keep the latency to a sane level.


The thing that seems to trip up this psql thing is the strict
requirement to always run the leftmost task. If all tasks have very
short runnable periods, we start interleaving between all contending
tasks. The way we're looking to solve this by weakening this leftmost
requirement so that a server/client pair can ping-pong for a while, then
switch to another pair which gets to ping-pong for a while.

This alternating pattern as opposed to the interleaving pattern is much
more friendly to the cache. And we should do it in such a manner that we
still ensure fairness and predictablilty and such.

The latest sched code contains a few patches in this direction
(.25-rc6), and they seem to have the desired effect on 1 socket single
and dual core and 8 socket single core and dual core. On quad core we
seem to have some load balance problems that destroy the workload in
other interresting ways - looking into that now.

- Peter


  reply	other threads:[~2008-03-17  9:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-11  6:49 Nick Piggin
2008-03-11  7:58 ` Ingo Molnar
2008-03-11  8:28   ` Nick Piggin
2008-03-11  9:59     ` Ingo Molnar
2008-03-11 21:07 ` Nicholas Miell
2008-03-11 21:34   ` Cyrus Massoumi
2008-03-11 23:12     ` Nicholas Miell
2008-03-11 23:42       ` Nick Piggin
2008-03-11 23:47       ` Stephen Hemminger
2008-03-12  9:00       ` Zhang, Yanmin
     [not found] ` <20080311102538.GA30551@elte.hu>
     [not found]   ` <20080311120230.GA5386@elte.hu>
2008-03-12  1:21     ` Nick Piggin
2008-03-12  7:58       ` Peter Zijlstra
2008-03-17  0:44         ` Nick Piggin
2008-03-17  5:16           ` Ray Lee
2008-03-17  5:21             ` Willy Tarreau
2008-03-17  7:19               ` Nick Piggin
2008-03-17  8:26                 ` Willy Tarreau
2008-03-17  8:54                   ` Nick Piggin
2008-03-17  9:28                     ` Peter Zijlstra [this message]
2008-03-17  9:56                       ` Nick Piggin
2008-03-17 10:16                       ` Ingo Molnar
2008-03-17  5:34             ` Nick Piggin
2008-03-14 15:42 Xose Vazquez Perez

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=1205746084.8514.301.camel@twins \
    --to=peterz@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=ray-lk@madrabbit.org \
    --cc=w@1wt.eu \
    --subject='Re: Poor PostgreSQL scaling on Linux 2.6.25-rc5 (vs 2.6.22)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).