Christoph Lameter writes:
> On Thu, 1 Jun 2017, Hugh Dickins wrote:
>
>> Thanks a lot for working that out. Makes sense, fully understood now,
>> nothing to worry about (though makes one wonder whether it's efficient
>> to use ctors on high-alignment caches; or whether an internal "zero-me"
>> c
Hugh Dickins writes:
> On Fri, 2 Jun 2017, Michael Ellerman wrote:
>> Hugh Dickins writes:
>> > On Thu, 1 Jun 2017, Christoph Lameter wrote:
>> >>
>> >> Ok so debugging was off but the slab cache has a ctor callback which
>> >> mandates that the free pointer cannot use the free object space when
On Thu, 1 Jun 2017, Hugh Dickins wrote:
> SLUB versus SLAB, cpu versus memory? Since someone has taken the
> trouble to write it with ctors in the past, I didn't feel on firm
> enough ground to recommend such a change. But it may be obvious
> to someone else that your suggestion would be better
On Thu, 1 Jun 2017, Hugh Dickins wrote:
> Thanks a lot for working that out. Makes sense, fully understood now,
> nothing to worry about (though makes one wonder whether it's efficient
> to use ctors on high-alignment caches; or whether an internal "zero-me"
> ctor would be useful).
Use kzalloc
Hugh Dickins writes:
> On Thu, 1 Jun 2017, Christoph Lameter wrote:
>>
>> Ok so debugging was off but the slab cache has a ctor callback which
>> mandates that the free pointer cannot use the free object space when
>> the object is not in use. Thus the size of the object must be increased to
>>
On Thu, 1 Jun 2017, Christoph Lameter wrote:
>
> Ok so debugging was off but the slab cache has a ctor callback which
> mandates that the free pointer cannot use the free object space when
> the object is not in use. Thus the size of the object must be increased to
> accomodate the freepointer.
T
On Thu, 1 Jun 2017, Hugh Dickins wrote:
> CONFIG_SLUB_DEBUG_ON=y. My SLAB|SLUB config options are
>
> CONFIG_SLUB_DEBUG=y
> # CONFIG_SLUB_MEMCG_SYSFS_ON is not set
> # CONFIG_SLAB is not set
> CONFIG_SLUB=y
> # CONFIG_SLAB_FREELIST_RANDOM is not set
> CONFIG_SLUB_CPU_PARTIAL=y
> CONFIG_SLABINFO=y
> > I am curious as to what is going on there. Do you have the output from
> > these failed allocations?
>
> I thought the relevant output was in my mail. I did skip the Mem-Info
> dump, since that just seemed noise in this case: we know memory can get
> fragmented. What more output are you loo
Hugh Dickins writes:
> Since f6eedbba7a26 ("powerpc/mm/hash: Increase VA range to 128TB")
> I find that swapping loads on ppc64 on G5 with 4k pages are failing:
>
> SLUB: Unable to allocate memory on node -1, gfp=0x14000c0(GFP_KERNEL)
> cache: pgtable-2^12, object size: 32768, buffer size: 6553
On Wed, May 31, 2017 at 8:44 PM, Hugh Dickins wrote:
> [ Merging two mails into one response ]
>
> On Wed, 31 May 2017, Christoph Lameter wrote:
>> On Tue, 30 May 2017, Hugh Dickins wrote:
>> > SLUB: Unable to allocate memory on node -1, gfp=0x14000c0(GFP_KERNEL)
>> > cache: pgtable-2^12, object
[ Merging two mails into one response ]
On Wed, 31 May 2017, Christoph Lameter wrote:
> On Tue, 30 May 2017, Hugh Dickins wrote:
> > SLUB: Unable to allocate memory on node -1, gfp=0x14000c0(GFP_KERNEL)
> > cache: pgtable-2^12, object size: 32768, buffer size: 65536, default
> > order: 4, min o
On Wed, 31 May 2017, Michael Ellerman wrote:
> > SLUB: Unable to allocate memory on node -1, gfp=0x14000c0(GFP_KERNEL)
> > cache: pgtable-2^12, object size: 32768, buffer size: 65536, default
> > order: 4, min order: 4
> > pgtable-2^12 debugging increased min order, use slub_debug=O to disabl
On Tue, 30 May 2017, Hugh Dickins wrote:
> I wanted to try removing CONFIG_SLUB_DEBUG, but didn't succeed in that:
> it seemed to be a hard requirement for something, but I didn't find what.
CONFIG_SLUB_DEBUG does not enable debugging. It only includes the code to
be able to enable it at runtime.
Hugh Dickins writes:
> Since f6eedbba7a26 ("powerpc/mm/hash: Increase VA range to 128TB")
> I find that swapping loads on ppc64 on G5 with 4k pages are failing:
>
> SLUB: Unable to allocate memory on node -1, gfp=0x14000c0(GFP_KERNEL)
> cache: pgtable-2^12, object size: 32768, buffer size: 6553
14 matches
Mail list logo
