All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org, linux-mm@vger.kernel.org
Subject: Re: [PATCH] Move slab objects to the end of the real allocation
Date: Mon, 22 Sep 2003 18:31:22 +0200	[thread overview]
Message-ID: <3F6F23DA.9020901@colorfullife.com> (raw)
In-Reply-To: <200309221733.37203.arnd@arndb.de>

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


  reply	other threads:[~2003-09-22 16:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-22 15:33 [PATCH] Move slab objects to the end of the real allocation Arnd Bergmann
2003-09-22 16:31 ` Manfred Spraul [this message]
2003-09-22 20:40   ` Arnd Bergmann
2003-09-22 20:53     ` Manfred Spraul
2003-09-23  2:52       ` Anton Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F6F23DA.9020901@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.