All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: Nick Piggin <npiggin-l3A5Bk7waGM@public.gmane.org>
Cc: Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	shaggy-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Subject: Re: [patch 2/2]: introduce fast_gup
Date: Fri, 28 Mar 2008 11:01:16 +0100	[thread overview]
Message-ID: <20080328100116.GH12346@kernel.dk> (raw)
In-Reply-To: <20080328030023.GC8083-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>

On Fri, Mar 28 2008, Nick Piggin wrote:
> 
> Introduce a new "fast_gup" (for want of a better name right now) which
> is basically a get_user_pages with a less general API (but still tends to
> be suited to the common case):

I did some quick tests here with two kernels - baseline was current -git
with the io cpu affinity stuff, nick is that same base but with your
fast_gup() applied. The test run was meant to show the best possible
scenario, 1 thread per disk (11 in total) with 4kb block size. Each
thread used async O_DIRECT reads, queue depth was 64.

For each kernel, a=0 means that completions were done normally and
a=1 means that completions were moved to the submitter. Total
runtime for each iteration is ~20 seconds, each test was run 3 times and
the scores averaged (very little deviation was seen between runs).

Kernel             bw         usr(sec)       sys(sec)           bw/sys
----------------------------------------------------------------------
baseline,a=0    306MiB/s     3.490          14.308              21.39
baseline,a=1    309MiB/s     3.717          13.718              22.53
nick,a=0        310MiB/s     3.669          13.804              22.46
nick,a=1        311MiB/s     3.686          13.279              23.42

That last number is just bandwidth/systime. So baseline vs your patch
gets about 5% better bw/sys utilization. fast_gup() + io affinity is
about 9.5% better bw/sys.

The system is just a puny 2-way x86-64, two sockets with HT enabled. So
I'd say the results look quite good!

-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	shaggy@austin.ibm.com, linux-mm@kvack.org,
	linux-arch@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [patch 2/2]: introduce fast_gup
Date: Fri, 28 Mar 2008 11:01:16 +0100	[thread overview]
Message-ID: <20080328100116.GH12346@kernel.dk> (raw)
Message-ID: <20080328100116.O-PSJ-D38Q2fIFBcFrhY8MlaieVjT11kqmV12sdDYK0@z> (raw)
In-Reply-To: <20080328030023.GC8083@wotan.suse.de>

On Fri, Mar 28 2008, Nick Piggin wrote:
> 
> Introduce a new "fast_gup" (for want of a better name right now) which
> is basically a get_user_pages with a less general API (but still tends to
> be suited to the common case):

I did some quick tests here with two kernels - baseline was current -git
with the io cpu affinity stuff, nick is that same base but with your
fast_gup() applied. The test run was meant to show the best possible
scenario, 1 thread per disk (11 in total) with 4kb block size. Each
thread used async O_DIRECT reads, queue depth was 64.

For each kernel, a=0 means that completions were done normally and
a=1 means that completions were moved to the submitter. Total
runtime for each iteration is ~20 seconds, each test was run 3 times and
the scores averaged (very little deviation was seen between runs).

Kernel             bw         usr(sec)       sys(sec)           bw/sys
----------------------------------------------------------------------
baseline,a=0    306MiB/s     3.490          14.308              21.39
baseline,a=1    309MiB/s     3.717          13.718              22.53
nick,a=0        310MiB/s     3.669          13.804              22.46
nick,a=1        311MiB/s     3.686          13.279              23.42

That last number is just bandwidth/systime. So baseline vs your patch
gets about 5% better bw/sys utilization. fast_gup() + io affinity is
about 9.5% better bw/sys.

The system is just a puny 2-way x86-64, two sockets with HT enabled. So
I'd say the results look quite good!

-- 
Jens Axboe


WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	shaggy@austin.ibm.com, linux-mm@kvack.org,
	linux-arch@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [patch 2/2]: introduce fast_gup
Date: Fri, 28 Mar 2008 11:01:16 +0100	[thread overview]
Message-ID: <20080328100116.GH12346@kernel.dk> (raw)
In-Reply-To: <20080328030023.GC8083@wotan.suse.de>

On Fri, Mar 28 2008, Nick Piggin wrote:
> 
> Introduce a new "fast_gup" (for want of a better name right now) which
> is basically a get_user_pages with a less general API (but still tends to
> be suited to the common case):

I did some quick tests here with two kernels - baseline was current -git
with the io cpu affinity stuff, nick is that same base but with your
fast_gup() applied. The test run was meant to show the best possible
scenario, 1 thread per disk (11 in total) with 4kb block size. Each
thread used async O_DIRECT reads, queue depth was 64.

For each kernel, a=0 means that completions were done normally and
a=1 means that completions were moved to the submitter. Total
runtime for each iteration is ~20 seconds, each test was run 3 times and
the scores averaged (very little deviation was seen between runs).

Kernel             bw         usr(sec)       sys(sec)           bw/sys
----------------------------------------------------------------------
baseline,a=0    306MiB/s     3.490          14.308              21.39
baseline,a=1    309MiB/s     3.717          13.718              22.53
nick,a=0        310MiB/s     3.669          13.804              22.46
nick,a=1        311MiB/s     3.686          13.279              23.42

That last number is just bandwidth/systime. So baseline vs your patch
gets about 5% better bw/sys utilization. fast_gup() + io affinity is
about 9.5% better bw/sys.

The system is just a puny 2-way x86-64, two sockets with HT enabled. So
I'd say the results look quite good!

-- 
Jens Axboe

--
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:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2008-03-28 10:01 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28  2:54 [patch 0/2]: lockless get_user_pages patchset Nick Piggin
2008-03-28  2:54 ` Nick Piggin
2008-03-28  2:54 ` Nick Piggin
     [not found] ` <20080328025455.GA8083-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-03-28  2:55   ` [patch 1/2]: x86: implement pte_special Nick Piggin
2008-03-28  2:55     ` Nick Piggin
2008-03-28  2:55     ` Nick Piggin
     [not found]     ` <20080328025541.GB8083-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-03-28  3:23       ` David Miller
2008-03-28  3:23         ` David Miller, Nick Piggin
2008-03-28  3:23         ` David Miller
     [not found]         ` <20080327.202334.250213398.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-03-28  3:31           ` Nick Piggin
2008-03-28  3:31             ` Nick Piggin
2008-03-28  3:31             ` Nick Piggin
     [not found]             ` <20080328033149.GD8083-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-03-28  3:44               ` David Miller
2008-03-28  3:44                 ` David Miller, Nick Piggin
2008-03-28  3:44                 ` David Miller
     [not found]                 ` <20080327.204431.201380891.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-03-28  4:04                   ` Nick Piggin
2008-03-28  4:04                     ` Nick Piggin
2008-03-28  4:04                     ` Nick Piggin
     [not found]                     ` <20080328040442.GE8083-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-03-28  4:09                       ` David Miller
2008-03-28  4:09                         ` David Miller, Nick Piggin
2008-03-28  4:09                         ` David Miller
     [not found]                         ` <20080327.210910.101408473.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-03-28  4:15                           ` Nick Piggin
2008-03-28  4:15                             ` Nick Piggin
2008-03-28  4:15                             ` Nick Piggin
     [not found]                             ` <20080328041519.GF8083-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-03-28  4:16                               ` David Miller
2008-03-28  4:16                                 ` David Miller, Nick Piggin
2008-03-28  4:16                                 ` David Miller
     [not found]                                 ` <20080327.211632.02770342.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-03-28  4:19                                   ` Nick Piggin
2008-03-28  4:19                                     ` Nick Piggin
2008-03-28  4:19                                     ` Nick Piggin
2008-03-28  4:17                               ` Nick Piggin
2008-03-28  4:17                                 ` Nick Piggin
2008-03-28  4:17                                 ` Nick Piggin
2008-03-28  3:00   ` [patch 2/2]: introduce fast_gup Nick Piggin
2008-03-28  3:00     ` Nick Piggin
2008-03-28  3:00     ` Nick Piggin
     [not found]     ` <20080328030023.GC8083-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-03-28 10:01       ` Jens Axboe [this message]
2008-03-28 10:01         ` Jens Axboe
2008-03-28 10:01         ` Jens Axboe
2008-04-17 15:03       ` Peter Zijlstra
2008-04-17 15:03         ` Peter Zijlstra
2008-04-17 15:03         ` Peter Zijlstra
2008-04-17 15:25         ` Linus Torvalds
2008-04-17 15:25           ` Linus Torvalds
2008-04-17 15:25           ` Linus Torvalds
     [not found]           ` <alpine.LFD.1.00.0804170814090.2879-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-17 16:12             ` Peter Zijlstra
2008-04-17 16:12               ` Peter Zijlstra
2008-04-17 16:12               ` Peter Zijlstra
2008-04-17 16:18               ` Linus Torvalds
2008-04-17 16:18                 ` Linus Torvalds
2008-04-17 16:18                 ` Linus Torvalds
     [not found]                 ` <alpine.LFD.1.00.0804170916470.2879-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-17 16:35                   ` Peter Zijlstra
2008-04-17 16:35                     ` Peter Zijlstra
2008-04-17 16:35                     ` Peter Zijlstra
2008-04-17 16:40                     ` Linus Torvalds
2008-04-17 16:40                       ` Linus Torvalds
2008-04-17 16:40                       ` Linus Torvalds
     [not found]                       ` <alpine.LFD.1.00.0804170940270.2879-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-17 17:23                         ` Peter Zijlstra
2008-04-17 17:23                           ` Peter Zijlstra
2008-04-17 17:23                           ` Peter Zijlstra
2008-04-17 18:28                           ` Linus Torvalds
2008-04-17 18:28                             ` Linus Torvalds
2008-04-17 18:28                             ` Linus Torvalds
     [not found]                             ` <alpine.LFD.1.00.0804171127310.2879-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-22  3:14                               ` Nick Piggin
2008-04-22  3:14                                 ` Nick Piggin
2008-04-22  3:14                                 ` Nick Piggin
2008-04-18  6:31                           ` Geert Uytterhoeven
2008-04-18  6:31                             ` Geert Uytterhoeven
2008-04-18  6:31                             ` Geert Uytterhoeven
2008-04-18 14:40                             ` Linus Torvalds
2008-04-18 14:40                               ` Linus Torvalds
2008-04-18 14:40                               ` Linus Torvalds
2008-04-18  9:58               ` Jeremy Fitzhardinge
2008-04-18  9:58                 ` Jeremy Fitzhardinge
2008-04-18  9:58                 ` Jeremy Fitzhardinge
2008-04-21 12:00             ` Avi Kivity
2008-04-21 12:00               ` Avi Kivity
2008-04-21 12:00               ` Avi Kivity
     [not found]               ` <480C81C4.8030200-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-04-21 12:30                 ` Peter Zijlstra
2008-04-21 12:30                   ` Peter Zijlstra
2008-04-21 12:30                   ` Peter Zijlstra
2008-04-21 13:26                   ` Avi Kivity
2008-04-21 13:26                     ` Avi Kivity
2008-04-21 13:26                     ` Avi Kivity
     [not found]                     ` <480C9619.2050201-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-04-21 14:35                       ` Peter Zijlstra
2008-04-21 14:35                         ` Peter Zijlstra
2008-04-21 14:35                         ` Peter Zijlstra
2008-04-22  3:23                         ` Nick Piggin
2008-04-22  3:23                           ` Nick Piggin
2008-04-22  3:23                           ` Nick Piggin
     [not found]                           ` <20080422032319.GB21993-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2008-04-22  7:19                             ` Avi Kivity
2008-04-22  7:19                               ` Avi Kivity
2008-04-22  7:19                               ` Avi Kivity
2008-04-22  8:07                             ` Ingo Molnar
2008-04-22  8:07                               ` Ingo Molnar
2008-04-22  8:07                               ` Ingo Molnar
2008-04-22  9:42       ` Peter Zijlstra
2008-04-22  9:42         ` Peter Zijlstra
2008-04-22  9:42         ` Peter Zijlstra
2008-04-22  9:46         ` Nick Piggin
2008-04-22  9:46           ` Nick Piggin
2008-04-22  9:46           ` Nick Piggin
2008-05-14 18:33           ` Dave Kleikamp
2008-05-14 18:33             ` Dave Kleikamp
2008-05-15  1:13             ` Nick Piggin
2008-05-15  1:13               ` Nick Piggin

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=20080328100116.GH12346@kernel.dk \
    --to=jens.axboe-qhclzuegtsvqt0dzr+alfa@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=npiggin-l3A5Bk7waGM@public.gmane.org \
    --cc=shaggy-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org \
    --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    /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.