On Thu, 16 Jan 2014, Dave Hansen wrote:
> This was a really tight loop where the caches are really hot, but it did
> show the large 'struct page' winning:
>
> http://sr71.net/~dave/intel/slub/slub-perf-20140109.png
>
> As I said in the earlier description, the paravirt code doing interrupt
On 01/16/2014 08:44 AM, Christoph Lameter wrote:
> On Tue, 14 Jan 2014, Dave Hansen wrote:
>
>> On 01/14/2014 12:07 PM, Christoph Lameter wrote:
>>> One easy way to shrink struct page is to simply remove the feature. The
>>> patchset looked a bit complicated and does many other things.
>>
>>
On Tue, 14 Jan 2014, Dave Hansen wrote:
> On 01/14/2014 12:07 PM, Christoph Lameter wrote:
> > One easy way to shrink struct page is to simply remove the feature. The
> > patchset looked a bit complicated and does many other things.
>
> Sure. There's a clear path if you only care about 'struct
On Tue, 14 Jan 2014, Dave Hansen wrote:
On 01/14/2014 12:07 PM, Christoph Lameter wrote:
One easy way to shrink struct page is to simply remove the feature. The
patchset looked a bit complicated and does many other things.
Sure. There's a clear path if you only care about 'struct page'
On 01/16/2014 08:44 AM, Christoph Lameter wrote:
On Tue, 14 Jan 2014, Dave Hansen wrote:
On 01/14/2014 12:07 PM, Christoph Lameter wrote:
One easy way to shrink struct page is to simply remove the feature. The
patchset looked a bit complicated and does many other things.
Sure. There's a
On Thu, 16 Jan 2014, Dave Hansen wrote:
This was a really tight loop where the caches are really hot, but it did
show the large 'struct page' winning:
http://sr71.net/~dave/intel/slub/slub-perf-20140109.png
As I said in the earlier description, the paravirt code doing interrupt
On 01/14/2014 12:07 PM, Christoph Lameter wrote:
> One easy way to shrink struct page is to simply remove the feature. The
> patchset looked a bit complicated and does many other things.
Sure. There's a clear path if you only care about 'struct page' size,
or if you only care about making the
One easy way to shrink struct page is to simply remove the feature. The
patchset looked a bit complicated and does many other things.
Subject: slub: Remove struct page alignment restriction by dropping
cmpxchg_double on struct page fields
Remove the logic that will do cmpxchg_doubles on struct
Dave: Please resend the newest form of the patchset. I do not have patch 0
and 1 and I do not see them on linux-mm.
On Sat, 11 Jan 2014, Christoph Lameter wrote:
> On Sat, 11 Jan 2014, Pekka Enberg wrote:
>
> > On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote:
> > > On 01/10/2014 03:39 PM,
Dave: Please resend the newest form of the patchset. I do not have patch 0
and 1 and I do not see them on linux-mm.
On Sat, 11 Jan 2014, Christoph Lameter wrote:
On Sat, 11 Jan 2014, Pekka Enberg wrote:
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen d...@sr71.net wrote:
On 01/10/2014 03:39
One easy way to shrink struct page is to simply remove the feature. The
patchset looked a bit complicated and does many other things.
Subject: slub: Remove struct page alignment restriction by dropping
cmpxchg_double on struct page fields
Remove the logic that will do cmpxchg_doubles on struct
On 01/14/2014 12:07 PM, Christoph Lameter wrote:
One easy way to shrink struct page is to simply remove the feature. The
patchset looked a bit complicated and does many other things.
Sure. There's a clear path if you only care about 'struct page' size,
or if you only care about making the slub
On 01/12/2014 05:44 PM, Joonsoo Kim wrote:
> We only touch one struct page on small allocation.
> In 64-byte case, we always use one cacheline for touching struct page, since
> it is aligned to cacheline size. However, in 56-byte case, we possibly use
> two cachelines because struct page isn't
On 01/13/2014 05:46 AM, Fengguang Wu wrote:
>>> So, I think
>>> that it is better to get more benchmark results to this patchset for
>>> convincing
>>> ourselves. If possible, how about asking Fengguang to run whole set of
>>> his benchmarks before going forward?
>>
>> Cc'ing him.
>
> My
> > So, I think
> > that it is better to get more benchmark results to this patchset for
> > convincing
> > ourselves. If possible, how about asking Fengguang to run whole set of
> > his benchmarks before going forward?
>
> Cc'ing him.
My pleasure. Is there a git tree for the patches? Git trees
So, I think
that it is better to get more benchmark results to this patchset for
convincing
ourselves. If possible, how about asking Fengguang to run whole set of
his benchmarks before going forward?
Cc'ing him.
My pleasure. Is there a git tree for the patches? Git trees
are most
On 01/13/2014 05:46 AM, Fengguang Wu wrote:
So, I think
that it is better to get more benchmark results to this patchset for
convincing
ourselves. If possible, how about asking Fengguang to run whole set of
his benchmarks before going forward?
Cc'ing him.
My pleasure. Is there a git
On 01/12/2014 05:44 PM, Joonsoo Kim wrote:
We only touch one struct page on small allocation.
In 64-byte case, we always use one cacheline for touching struct page, since
it is aligned to cacheline size. However, in 56-byte case, we possibly use
two cachelines because struct page isn't aligned
On Mon, 2014-01-13 at 10:44 +0900, Joonsoo Kim wrote:
> On Sat, Jan 11, 2014 at 06:55:39PM -0600, Christoph Lameter wrote:
> > On Sat, 11 Jan 2014, Pekka Enberg wrote:
> >
> > > On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote:
> > > > On 01/10/2014 03:39 PM, Andrew Morton wrote:
> > > >>> I
On Sat, Jan 11, 2014 at 06:55:39PM -0600, Christoph Lameter wrote:
> On Sat, 11 Jan 2014, Pekka Enberg wrote:
>
> > On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote:
> > > On 01/10/2014 03:39 PM, Andrew Morton wrote:
> > >>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The
On Sat, Jan 11, 2014 at 06:55:39PM -0600, Christoph Lameter wrote:
On Sat, 11 Jan 2014, Pekka Enberg wrote:
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen d...@sr71.net wrote:
On 01/10/2014 03:39 PM, Andrew Morton wrote:
I tested 4 cases, all of these on the cache-cold kfree() case. The
On Mon, 2014-01-13 at 10:44 +0900, Joonsoo Kim wrote:
On Sat, Jan 11, 2014 at 06:55:39PM -0600, Christoph Lameter wrote:
On Sat, 11 Jan 2014, Pekka Enberg wrote:
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen d...@sr71.net wrote:
On 01/10/2014 03:39 PM, Andrew Morton wrote:
I tested
On Sat, 11 Jan 2014, Pekka Enberg wrote:
> On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote:
> > On 01/10/2014 03:39 PM, Andrew Morton wrote:
> >>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The
> >>> first 3 are with vanilla upstream kernel source. The 4th is patched
>
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote:
> On 01/10/2014 03:39 PM, Andrew Morton wrote:
>>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The
>>> first 3 are with vanilla upstream kernel source. The 4th is patched
>>> with my new slub code (all single-threaded):
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen d...@sr71.net wrote:
On 01/10/2014 03:39 PM, Andrew Morton wrote:
I tested 4 cases, all of these on the cache-cold kfree() case. The
first 3 are with vanilla upstream kernel source. The 4th is patched
with my new slub code (all single-threaded):
On Sat, 11 Jan 2014, Pekka Enberg wrote:
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen d...@sr71.net wrote:
On 01/10/2014 03:39 PM, Andrew Morton wrote:
I tested 4 cases, all of these on the cache-cold kfree() case. The
first 3 are with vanilla upstream kernel source. The 4th is patched
On 01/10/2014 03:39 PM, Andrew Morton wrote:
>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The
>> first 3 are with vanilla upstream kernel source. The 4th is patched
>> with my new slub code (all single-threaded):
>>
>>
On Fri, 10 Jan 2014 12:52:32 -0800 Dave Hansen wrote:
> On 01/05/2014 08:32 PM, Joonsoo Kim wrote:
> > On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
> >> On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen wrote:
> >>> SLUB depends on a 16-byte cmpxchg for an optimization which
>
On 01/05/2014 08:32 PM, Joonsoo Kim wrote:
> On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
>> On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen wrote:
>>> SLUB depends on a 16-byte cmpxchg for an optimization which
>>> allows it to not disable interrupts in its fast path. This
>>>
On 01/05/2014 08:32 PM, Joonsoo Kim wrote:
On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen d...@sr71.net wrote:
SLUB depends on a 16-byte cmpxchg for an optimization which
allows it to not disable interrupts in its fast path. This
On Fri, 10 Jan 2014 12:52:32 -0800 Dave Hansen d...@sr71.net wrote:
On 01/05/2014 08:32 PM, Joonsoo Kim wrote:
On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen d...@sr71.net wrote:
SLUB depends on a 16-byte cmpxchg for an
On 01/10/2014 03:39 PM, Andrew Morton wrote:
I tested 4 cases, all of these on the cache-cold kfree() case. The
first 3 are with vanilla upstream kernel source. The 4th is patched
with my new slub code (all single-threaded):
http://www.sr71.net/~dave/intel/slub/slub-perf-20140109.png
On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
> On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen wrote:
>
> > This is a minor update from the last version. The most notable
> > thing is that I was able to demonstrate that maintaining the
> > cmpxchg16 optimization has _some_
On Fri, Jan 03, 2014 at 02:18:16PM -0800, Andrew Morton wrote:
On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen d...@sr71.net wrote:
This is a minor update from the last version. The most notable
thing is that I was able to demonstrate that maintaining the
cmpxchg16 optimization has _some_
On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen wrote:
> This is a minor update from the last version. The most notable
> thing is that I was able to demonstrate that maintaining the
> cmpxchg16 optimization has _some_ value.
>
> Otherwise, the code changes are just a few minor cleanups.
>
>
On Fri, 03 Jan 2014 10:01:47 -0800 Dave Hansen d...@sr71.net wrote:
This is a minor update from the last version. The most notable
thing is that I was able to demonstrate that maintaining the
cmpxchg16 optimization has _some_ value.
Otherwise, the code changes are just a few minor
36 matches
Mail list logo
