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 <><
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
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 <><
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
> 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