Re: [PATCH] Move slab objects to the end of the real allocation

Re: [PATCH] Move slab objects to the end of the real allocation

[Arnd Bergmann]

Manfred Spraul wrote:
>    - Do not page-pad allocations that are <= SMP_CACHE_LINE_SIZE.  This
>      crashes.  Right now the limit is hardcoded to 128 bytes, but sooner or
>      later an arch will appear with 256 byte cache lines.

What made you think that 128 is the current maximum? All s390 machines
have 256 byte cache lines.

	Arnd <><

Re: [PATCH] Move slab objects to the end of the real allocation

[Manfred Spraul]

Arnd Bergmann wrote:

>Manfred Spraul wrote:
>  
>
>>   - Do not page-pad allocations that are <= SMP_CACHE_LINE_SIZE.  This
>>     crashes.  Right now the limit is hardcoded to 128 bytes, but sooner or
>>     later an arch will appear with 256 byte cache lines.
>>    
>>
>
>What made you think that 128 is the current maximum? All s390 machines
>have 256 byte cache lines.
>  
>
When I wrote "128" I was not aware that this is linked to the cache line 
size. Initially it was ">128", just as an arbitrary number. I replaced 
that with "> 116" due to an unrelated change, and that crashed, because 
the cache line size was set to 128 bytes.

My patch fixes this bug: It replaces the limits with >=116 [avoid 
wasting too much memory, guarantee that there is a cache for the 
off-slab control structures] and > SMP_CACHE_LINE_SIZE [guarantee that 
there is a cache for the off-slab control structures].

Right now there are too many patches in Andrew's tree, I'll wait until 
everything settled down a bit, then I'll resent the cache line size as a 
one-line patch. Do you want to implement CONFIG_DEBUG_PAGEALLOC 
immediately? If yes, then I can send you the oneliner immediately. 
Nothing except CONFIG_DEBUG_PAGEALLOC is affected by the bug.

--
    Manfred

Re: [PATCH] Move slab objects to the end of the real allocation

[Arnd Bergmann]

On Monday 22 September 2003 18:31, Manfred Spraul wrote:
> Right now there are too many patches in Andrew's tree, I'll wait until
> everything settled down a bit, then I'll resent the cache line size as a
> one-line patch. Do you want to implement CONFIG_DEBUG_PAGEALLOC
> immediately? If yes, then I can send you the oneliner immediately.
> Nothing except CONFIG_DEBUG_PAGEALLOC is affected by the bug.

Thanks for the explanation. I didn't realize that the code only applies
to i386. I'm not trying to implement CONFIG_DEBUG_PAGEALLOC currently,
but I'll put it on my list of things to do. Do I need to do anything
beyond adding a working kernel_map_pages() and raising the 128 byte limit
in kmem_cache_create to max(128,L1_CACHE_BYTES)?

	Arnd <><

Re: [PATCH] Move slab objects to the end of the real allocation

[Manfred Spraul]

Arnd Bergmann wrote:

>On Monday 22 September 2003 18:31, Manfred Spraul wrote:
>  
>
>>Right now there are too many patches in Andrew's tree, I'll wait until
>>everything settled down a bit, then I'll resent the cache line size as a
>>one-line patch. Do you want to implement CONFIG_DEBUG_PAGEALLOC
>>immediately? If yes, then I can send you the oneliner immediately.
>>Nothing except CONFIG_DEBUG_PAGEALLOC is affected by the bug.
>>    
>>
>
>Thanks for the explanation. I didn't realize that the code only applies
>to i386. I'm not trying to implement CONFIG_DEBUG_PAGEALLOC currently,
>but I'll put it on my list of things to do. Do I need to do anything
>beyond adding a working kernel_map_pages() and raising the 128 byte limit
>in kmem_cache_create to max(128,L1_CACHE_BYTES)?
>  
>
I'm not aware of any other restrictions, but I think s390 would be the 
first arch beyond i386 that supports DEBUG_PAGEALLOC, so beware. One 
important point is that kernel_map_pages() can be called from irq 
context - I'm not sure if all archs can support that.

--
    Manfred

Re: [PATCH] Move slab objects to the end of the real allocation

[Anton Blanchard]

> I'm not aware of any other restrictions, but I think s390 would be the 
> first arch beyond i386 that supports DEBUG_PAGEALLOC, so beware. One 
> important point is that kernel_map_pages() can be called from irq 
> context - I'm not sure if all archs can support that.

Its working somewhat on ppc64. (somewhat because I dont have an easy way
to read protect pages from the kernel but I can write protect them.)

Anton