linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Nick Piggin <piggin@cyberone.com.au>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Nick's scheduler policy
Date: Sun, 24 Aug 2003 09:55:03 -0700	[thread overview]
Message-ID: <29760000.1061744102@[10.10.2.4]> (raw)
In-Reply-To: <3F48B12F.4070001@cyberone.com.au>

Seems to do badly with CPU intensive tasks:

Kernbench: (make -j vmlinux, maximal tasks)
                              Elapsed      System        User         CPU
              2.6.0-test3       46.00      115.49      571.94     1494.25
         2.6.0-test4-nick       49.37      131.31      611.15     1500.75

Oddly, schedule itself is significantly cheaper, but you seem
to end up with much more expense elsewhere. Thrashing tasks between
CPUs, maybe (esp given the increased user time)? I'll do a proper 
baseline against test4, but I don't expect it to be any different, really.

diffprofile {2.6.0-test3,2.6.0-test4-nick}/kernbench/0/profile
     12314     7.4% total
      3843    16.3% page_remove_rmap
      1657    20.8% __d_lookup
      1322     9.4% do_anonymous_page
      1143    21.5% __copy_to_user_ll
      1034    55.3% atomic_dec_and_lock
       683    48.4% free_hot_cold_page
       669   393.5% filp_close
       553   147.5% .text.lock.file_table
       484   479.2% file_ra_state_init
       409    24.3% buffered_rmqueue
       391    24.9% kmem_cache_free
       362    11.3% zap_pte_range
       304    16.5% path_lookup
       247    31.5% pte_alloc_one
       237    68.3% pgd_ctor
       229    19.0% file_move
       224    16.7% link_path_walk
       220    57.7% file_kill
       188     7.9% do_no_page
       164    24.6% __wake_up
       162     4.4% find_get_page
       146    24.4% generic_file_open
       141    87.6% .text.lock.dcache
       139    11.5% release_pages
       131    51.4% vfs_read
       127    40.2% dnotify_parent
...
      -144    -4.2% __copy_from_user_ll
      -149    -2.3% page_add_rmap
      -352   -25.1% schedule
     -3469    -6.8% default_idle


  parent reply	other threads:[~2003-08-24 16:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-24 12:35 [PATCH] Nick's scheduler policy Nick Piggin
2003-08-24 14:29 ` Felipe Alfaro Solana
2003-08-25  3:05   ` Nick Piggin
2003-08-25 22:30   ` Bill Davidsen
2003-08-24 16:55 ` Martin J. Bligh [this message]
2003-08-25  3:00   ` Nick Piggin
2003-08-25 10:41     ` [PATCH] Nick's scheduler policy v7 Nick Piggin
2003-08-25 11:03       ` Felipe Alfaro Solana
2003-08-25 14:36       ` Måns Rullgård
2003-08-26  3:24       ` Martin J. Bligh
2003-08-26  4:04         ` Nick Piggin
2003-08-26  9:44       ` Yaroslav Rastrigin
2003-08-27  9:28       ` Mike Galbraith
2003-08-25  3:27 ` [PATCH] Nick's scheduler policy Randy.Dunlap
2003-08-25  3:36   ` Nick Piggin
2003-08-26  3:16     ` Mike Fedyk

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='29760000.1061744102@[10.10.2.4]' \
    --to=mbligh@aracnet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piggin@cyberone.com.au \
    /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 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).