public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Paul Mundt <lethal@linux-sh.org>,
	linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-mm@vger.kernel.org,
	Christoph Lameter <cl@linux-foundation.org>
Subject: Re: [PATCH] slab: fix slab flags for archs use alignment larger  64-bit
Date: Fri, 13 Feb 2009 11:46:50 +0100	[thread overview]
Message-ID: <49954F9A.5020801@st.com> (raw)
In-Reply-To: <84144f020902130122y471dd92em4a72de43a0cfc681@mail.gmail.com>

Hi Pekka,
thanks for your prompt feedback.
Feel free to ask again if you need some other information.

Peppe

Kernel 2.6.23.17
=============================================
1) LOG with my patch:
root@linux:~# cat /proc/meminfo | grep Slab
Slab:             2612 kB

root@linux:~# cat /proc/slab_allocators
rpc_buffers: 8 mempool_alloc_slab+0x10/0x1c
rpc_tasks: 11 mempool_alloc_slab+0x10/0x1c
rpc_inode_cache: 10 rpc_alloc_inode+0x10/0x2c
...
anon_vma: 62 anon_vma_prepare+0x38/0xd4
pid: 20 alloc_pid+0x1e/0x2cc
size-2048: 1 tty_write+0xac/0x1d8
size-2048: 1 alloc_netdev_mq+0x40/0xbc
...

=============================================
2) LOG without my patch:
root@linux:~# cat /proc/meminfo | grep Slab
Slab:             2504 kB

root@linux:~# cat /proc/slab_allocators
rpc_buffers: 8 mempool_alloc_slab+0x10/0x1c
rpc_tasks: 11 mempool_alloc_slab+0x10/0x1c
rpc_inode_cache: 10 rpc_alloc_inode+0x10/0x2c
...
pid: 20 alloc_pid+0x1e/0x2cc

Pekka Enberg wrote:
> Hi Giuseppe,
>
> On Fri, Feb 13, 2009 at 12:00 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>   
>> IIUC, and as you explained above, ralign is already set to the cache
>> line size by the following code:
>> ...
>> /* 3) caller mandated alignment */
>> if (ralign < align)
>> ralign = align;
>>
>> Then, there is following check:
>> ...
>> /* disable debug if necessary */
>> if (ralign > _alignof__(unsigned long long))
>> flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
>>
>> In my point of view, just this check appears "incoherent" (please, note
>> I'm not familiar with the slab internals).
>> It always makes sense in case of x86 where ARCH_KMALLOC_MINALIGN is
>> defined as: __alignof__(unsigned long long) as well.
>>     
>
> The code is indeed quite cryptic but I don't think the above statement
> is correct. Both SLAB_RED_ZONE and SLAB_STORE_USER add padding in
> front of an object and the maximum size of that padding is 2 *
> sizeof(unsigned long long). That's why we check for
> __alignof__(unsigned long) there to make sure the object can begin
> immediately after the padding added for red-zone and user pointer.
>
> On Fri, Feb 13, 2009 at 12:00 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>   
>> In case of sh, we always disable debug for 32 aligned objects. As side
>> effect, within the leaks_show function we immediately exit for them.
>> Indeed, after applying the patch, I attached, I was able to find size-X
>> fields within the slab_allocators proc entry.
>>     
>
> That sounds unfortunate. Can you post
>
>   cat /proc/meminfo | grep Slab
>
> results on sh without and with your patch? Bumping the limit up to
> ARCH_KMALLOC_MINALIGN does make sense but we'd need to know what kind
> of problems it might cause.
>
>                                 Pekka
>
>   


  parent reply	other threads:[~2009-02-13  9:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-12 17:51 [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Giuseppe CAVALLARO
2009-02-12 18:56 ` Paul Mundt
2009-02-13 10:00   ` Giuseppe CAVALLARO
2009-02-13  9:22     ` Pekka Enberg
2009-02-13  9:30       ` Pekka Enberg
2009-02-13 10:46       ` Giuseppe CAVALLARO [this message]
2009-02-13 10:05         ` Pekka Enberg
2009-02-13 11:15           ` Giuseppe CAVALLARO
2009-02-13 14:11             ` Giuseppe CAVALLARO
2009-02-13 13:41               ` Pekka Enberg
2009-02-18  9:30                 ` Giuseppe CAVALLARO

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=49954F9A.5020801@st.com \
    --to=peppe.cavallaro@st.com \
    --cc=cl@linux-foundation.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox