From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by kanga.kvack.org (Postfix) with ESMTP id 46B306B006E for ; Fri, 21 Nov 2014 01:30:03 -0500 (EST) Received: by mail-pd0-f181.google.com with SMTP id z10so4643694pdj.12 for ; Thu, 20 Nov 2014 22:30:02 -0800 (PST) Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com. [210.118.77.13]) by mx.google.com with ESMTPS id wn6si6144428pac.222.2014.11.20.22.30.01 for (version=TLSv1 cipher=RC4-MD5 bits=128/128); Thu, 20 Nov 2014 22:30:02 -0800 (PST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NFD0010GM6P4P40@mailout3.w1.samsung.com> for linux-mm@kvack.org; Fri, 21 Nov 2014 06:32:49 +0000 (GMT) Message-id: <546EDBE0.10103@samsung.com> Date: Fri, 21 Nov 2014 09:29:52 +0300 From: Andrey Ryabinin MIME-version: 1.0 Subject: Re: [PATCH 1/3] mm: sl[aou]b: introduce kmem_cache_zalloc_node() References: <1415621218-6438-1-git-send-email-a.ryabinin@samsung.com> <546DAA99.5070402@samsung.com> In-reply-to: Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, Christoph Lameter , Andrew Morton , linux-mm@kvack.org, Pekka Enberg On 11/21/2014 01:31 AM, David Rientjes wrote: > On Thu, 20 Nov 2014, Andrey Ryabinin wrote: > >>> Is there a reason to add this for such a specialized purpose to the slab >>> allocator? I think it can just be handled for struct irq_desc explicitly. >>> >> >> It could be used not only for irq_desc. Grepping sources gave me 7 possible users. >> > > It would be best to follow in the example of those users and just use > __GFP_ZERO. > Fair enough. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757545AbaKUGaV (ORCPT ); Fri, 21 Nov 2014 01:30:21 -0500 Received: from [210.118.77.13] ([210.118.77.13]:45288 "EHLO mailout3.w1.samsung.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750766AbaKUGaT (ORCPT ); Fri, 21 Nov 2014 01:30:19 -0500 X-AuditID: cbfec7f5-b7f956d000005ed7-ca-546edbe50e8b Message-id: <546EDBE0.10103@samsung.com> Date: Fri, 21 Nov 2014 09:29:52 +0300 From: Andrey Ryabinin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-version: 1.0 To: David Rientjes Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, Christoph Lameter , Andrew Morton , linux-mm@kvack.org, Pekka Enberg Subject: Re: [PATCH 1/3] mm: sl[aou]b: introduce kmem_cache_zalloc_node() References: <1415621218-6438-1-git-send-email-a.ryabinin@samsung.com> <546DAA99.5070402@samsung.com> In-reply-to: Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsVy+t/xK7pPb+eFGCycLG8xZ/0aNovr394w WlzeNYfN4t6a/6wWbZ//AYklG5ksNm+ayuzA7rFgU6nHplWdbB6bPk1i93h37hy7x4kZv1k8 nlyZzuTxeZNcAHsUl01Kak5mWWqRvl0CV0bbqhtMBdeYK+6cuMXawPiSqYuRk0NCwETiyJ6V ULaYxIV769m6GLk4hASWMkpMnz2JHcJpZpK49mgXI0gVr4CGxK/tv1hBbBYBVYl1f3rZQWw2 AT2Jf7O2s4HYogIRElfWzIGqF5T4MfkeC4gtAtTbNuM/2AZmgXOMElNmXgVbLSzgKTFx8lmo 1a8YJQ4s/g/UwcHBKeAjMf0jP4jJDLTg/kUtkHJmAXmJzWveMk9gFJiFZMUshKpZSKoWMDKv YhRNLU0uKE5KzzXSK07MLS7NS9dLzs/dxAgJ+687GJceszrEKMDBqMTDe2FWbogQa2JZcWXu IUYJDmYlEd7yi3khQrwpiZVVqUX58UWlOanFhxiZODilGhidg5afYrpoefXLTtsqv0t7FCbv yZL5fHVziN+k0OqtJ9cLnDQVX8S/ZKPaT2Xu9pkF9S3ii2wO/81vbupY+Ynzwk/xf4W9+xaf n3qj6r6i09fP2ov3zV0WwRoX7a765F61gTn3wWl9vNa3Q133dsxgtz0apZjkMqmZXTYnq165 Qvnf07dnZH2UWIozEg21mIuKEwEoAmbpWQIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/21/2014 01:31 AM, David Rientjes wrote: > On Thu, 20 Nov 2014, Andrey Ryabinin wrote: > >>> Is there a reason to add this for such a specialized purpose to the slab >>> allocator? I think it can just be handled for struct irq_desc explicitly. >>> >> >> It could be used not only for irq_desc. Grepping sources gave me 7 possible users. >> > > It would be best to follow in the example of those users and just use > __GFP_ZERO. > Fair enough.