On 08/22/2013 10:44 AM, Christoph Lameter wrote:
> On Wed, 21 Aug 2013, Andrew Morton wrote:
>
>> The lock is needed so that one cpu can steal tags from another cpu's cache.
>> See (the needlessly inlined!) steal_tags().
>
> Stealing tags could also be done via IPIs or some other things.
That
On Wed, 21 Aug 2013, Andrew Morton wrote:
> The lock is needed so that one cpu can steal tags from another cpu's cache.
> See (the needlessly inlined!) steal_tags().
Stealing tags could also be done via IPIs or some other things.
--
To unsubscribe from this list: send the line "unsubscribe
On Wed, 21 Aug 2013, Andrew Morton wrote:
The lock is needed so that one cpu can steal tags from another cpu's cache.
See (the needlessly inlined!) steal_tags().
Stealing tags could also be done via IPIs or some other things.
--
To unsubscribe from this list: send the line unsubscribe
On 08/22/2013 10:44 AM, Christoph Lameter wrote:
On Wed, 21 Aug 2013, Andrew Morton wrote:
The lock is needed so that one cpu can steal tags from another cpu's cache.
See (the needlessly inlined!) steal_tags().
Stealing tags could also be done via IPIs or some other things.
That is
Hello, Kent.
On Wed, Aug 21, 2013 at 02:24:42PM -0700, Kent Overstreet wrote:
> With single page allocations:
>
> 1 << 15 bits per page
>
> 1 << 9 pointers per page
>
> So two layers of pointers does get us to 1 << 33 bits, which is what we
> need.
And single layer - 1 << 15 - would cover
On Wed, Aug 21, 2013 at 05:16:50PM -0400, Tejun Heo wrote:
> Hello, Kent.
>
> On Wed, Aug 21, 2013 at 02:09:01PM -0700, Kent Overstreet wrote:
> > These "micro optimizations" mean either less pointer chasing or less
> > branching in the _common_ case; you'd trade common case performance for
> >
Hello, Kent.
On Wed, Aug 21, 2013 at 02:09:01PM -0700, Kent Overstreet wrote:
> These "micro optimizations" mean either less pointer chasing or less
> branching in the _common_ case; you'd trade common case performance for
> avoiding ever doing higher order allocations (and 2 with COMPACTION=n
>
On Wed, Aug 21, 2013 at 07:59:41AM -0400, Tejun Heo wrote:
> Hello, Kent.
>
> On Tue, Aug 20, 2013 at 07:31:51PM -0700, Kent Overstreet wrote:
> > All this for a performance improvement of 10x to 50x (or more), for the
> > ida sizes I measured.
>
> That's misleading, isn't it?
It's comparing
On Wed, 21 Aug 2013 14:32:55 + Christoph Lameter wrote:
> On Tue, 20 Aug 2013, Nicholas A. Bellinger wrote:
>
> > On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
> > > On Wed, 7 Aug 2013, Kent Overstreet wrote:
> > >
> > > > One thing that was bugging me - I was never able to
On Wed, 2013-08-21 at 14:32 +, Christoph Lameter wrote:
> On Tue, 20 Aug 2013, Nicholas A. Bellinger wrote:
>
> > On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
> > > On Wed, 7 Aug 2013, Kent Overstreet wrote:
> > >
> > > > One thing that was bugging me - I was never able to
On Tue, 20 Aug 2013, Nicholas A. Bellinger wrote:
> On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
> > On Wed, 7 Aug 2013, Kent Overstreet wrote:
> >
> > > One thing that was bugging me - I was never able to figure out for sure
> > > if smp_processor_id() returns a number in the
Hello, Kent.
On Tue, Aug 20, 2013 at 07:31:51PM -0700, Kent Overstreet wrote:
> All this for a performance improvement of 10x to 50x (or more), for the
> ida sizes I measured.
That's misleading, isn't it? We should see large performance
improvements even without the large pages. What matters
Hello, Kent.
On Tue, Aug 20, 2013 at 07:31:51PM -0700, Kent Overstreet wrote:
All this for a performance improvement of 10x to 50x (or more), for the
ida sizes I measured.
That's misleading, isn't it? We should see large performance
improvements even without the large pages. What matters
On Tue, 20 Aug 2013, Nicholas A. Bellinger wrote:
On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
On Wed, 7 Aug 2013, Kent Overstreet wrote:
One thing that was bugging me - I was never able to figure out for sure
if smp_processor_id() returns a number in the range [0,
On Wed, 2013-08-21 at 14:32 +, Christoph Lameter wrote:
On Tue, 20 Aug 2013, Nicholas A. Bellinger wrote:
On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
On Wed, 7 Aug 2013, Kent Overstreet wrote:
One thing that was bugging me - I was never able to figure out for
On Wed, 21 Aug 2013 14:32:55 + Christoph Lameter c...@linux.com wrote:
On Tue, 20 Aug 2013, Nicholas A. Bellinger wrote:
On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
On Wed, 7 Aug 2013, Kent Overstreet wrote:
One thing that was bugging me - I was never able to
On Wed, Aug 21, 2013 at 07:59:41AM -0400, Tejun Heo wrote:
Hello, Kent.
On Tue, Aug 20, 2013 at 07:31:51PM -0700, Kent Overstreet wrote:
All this for a performance improvement of 10x to 50x (or more), for the
ida sizes I measured.
That's misleading, isn't it?
It's comparing it to the
Hello, Kent.
On Wed, Aug 21, 2013 at 02:09:01PM -0700, Kent Overstreet wrote:
These micro optimizations mean either less pointer chasing or less
branching in the _common_ case; you'd trade common case performance for
avoiding ever doing higher order allocations (and 2 with COMPACTION=n
and 4
On Wed, Aug 21, 2013 at 05:16:50PM -0400, Tejun Heo wrote:
Hello, Kent.
On Wed, Aug 21, 2013 at 02:09:01PM -0700, Kent Overstreet wrote:
These micro optimizations mean either less pointer chasing or less
branching in the _common_ case; you'd trade common case performance for
avoiding
Hello, Kent.
On Wed, Aug 21, 2013 at 02:24:42PM -0700, Kent Overstreet wrote:
With single page allocations:
1 15 bits per page
1 9 pointers per page
So two layers of pointers does get us to 1 33 bits, which is what we
need.
And single layer - 1 15 - would cover most of the use
On Tue, Aug 20, 2013 at 10:07:42PM -0400, Tejun Heo wrote:
> Hello, Kent.
>
> On Tue, Aug 20, 2013 at 07:01:32PM -0700, Kent Overstreet wrote:
> > I think Tejun and I might be at a bit of an impasse with the ida rewrite
> > itself, but I don't think there were any outstanding objections to the
>
Hello, Kent.
On Tue, Aug 20, 2013 at 07:01:32PM -0700, Kent Overstreet wrote:
> I think Tejun and I might be at a bit of an impasse with the ida rewrite
> itself, but I don't think there were any outstanding objections to the
> percpu ida code itself - and this is a standalone version.
The
On Tue, Aug 20, 2013 at 02:29:56PM -0700, Andrew Morton wrote:
> On Tue, 20 Aug 2013 14:19:06 -0700 "Nicholas A. Bellinger"
> wrote:
>
> > On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
> > > On Wed, 7 Aug 2013, Kent Overstreet wrote:
> > >
> > > > One thing that was bugging me -
On Tue, 20 Aug 2013 14:19:06 -0700 "Nicholas A. Bellinger"
wrote:
> On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
> > On Wed, 7 Aug 2013, Kent Overstreet wrote:
> >
> > > One thing that was bugging me - I was never able to figure out for sure
> > > if smp_processor_id() returns a
On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
> On Wed, 7 Aug 2013, Kent Overstreet wrote:
>
> > One thing that was bugging me - I was never able to figure out for sure
> > if smp_processor_id() returns a number in the range [0, nr_cpu_ids), at
> > least I couldn't find where it was
On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
On Wed, 7 Aug 2013, Kent Overstreet wrote:
One thing that was bugging me - I was never able to figure out for sure
if smp_processor_id() returns a number in the range [0, nr_cpu_ids), at
least I couldn't find where it was
On Tue, 20 Aug 2013 14:19:06 -0700 Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
On Wed, 7 Aug 2013, Kent Overstreet wrote:
One thing that was bugging me - I was never able to figure out for sure
if smp_processor_id()
On Tue, Aug 20, 2013 at 02:29:56PM -0700, Andrew Morton wrote:
On Tue, 20 Aug 2013 14:19:06 -0700 Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
On Thu, 2013-08-08 at 14:32 +, Christoph Lameter wrote:
On Wed, 7 Aug 2013, Kent Overstreet wrote:
One thing that was bugging me
Hello, Kent.
On Tue, Aug 20, 2013 at 07:01:32PM -0700, Kent Overstreet wrote:
I think Tejun and I might be at a bit of an impasse with the ida rewrite
itself, but I don't think there were any outstanding objections to the
percpu ida code itself - and this is a standalone version.
The percpu
On Tue, Aug 20, 2013 at 10:07:42PM -0400, Tejun Heo wrote:
Hello, Kent.
On Tue, Aug 20, 2013 at 07:01:32PM -0700, Kent Overstreet wrote:
I think Tejun and I might be at a bit of an impasse with the ida rewrite
itself, but I don't think there were any outstanding objections to the
percpu
On Wed, 7 Aug 2013, Kent Overstreet wrote:
> One thing that was bugging me - I was never able to figure out for sure
> if smp_processor_id() returns a number in the range [0, nr_cpu_ids), at
> least I couldn't find where it was documented - could you tell me if
> that's true?
I always assumed
On Wed, 7 Aug 2013, Kent Overstreet wrote:
One thing that was bugging me - I was never able to figure out for sure
if smp_processor_id() returns a number in the range [0, nr_cpu_ids), at
least I couldn't find where it was documented - could you tell me if
that's true?
I always assumed that
the range [0, nr_cpu_ids), at
least I couldn't find where it was documented - could you tell me if
that's true?
>From e2b8016de49c28c0ccbe7849d7254f005c7e2e77 Mon Sep 17 00:00:00 2001
From: Kent Overstreet
Date: Wed, 7 Aug 2013 12:52:58 -0700
Subject: [PATCH] idr: Use this_cpu_ptr() for percpu_ida
diff
tell me if
that's true?
From e2b8016de49c28c0ccbe7849d7254f005c7e2e77 Mon Sep 17 00:00:00 2001
From: Kent Overstreet k...@daterainc.com
Date: Wed, 7 Aug 2013 12:52:58 -0700
Subject: [PATCH] idr: Use this_cpu_ptr() for percpu_ida
diff --git a/lib/idr.c b/lib/idr.c
index fb374c3..320ffea 100644
34 matches
Mail list logo
