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>
next prev 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.