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.
>>
>> Sure.
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 pa
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 slu
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
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.
These are still of RFC quality. They're stable, but definitely
needs some wider testing, especially on 32-bit. Mostly just
resendi
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, And
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 alig
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
> > 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
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 te
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, 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 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-201
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
>>> o
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_ value
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.
>
> --
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.
---
SLUB depends on a 16-byte cmpxchg for an optimization which
allows
20 matches
Mail list logo
