From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45FA2C432C2 for ; Thu, 26 Sep 2019 00:14:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2110C20872 for ; Thu, 26 Sep 2019 00:14:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387641AbfIZAOp (ORCPT ); Wed, 25 Sep 2019 20:14:45 -0400 Received: from gentwo.org ([3.19.106.255]:49630 "EHLO gentwo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733141AbfIZAOp (ORCPT ); Wed, 25 Sep 2019 20:14:45 -0400 Received: by gentwo.org (Postfix, from userid 1002) id 17D1D3EEC6; Thu, 26 Sep 2019 00:14:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 150213E86C; Thu, 26 Sep 2019 00:14:44 +0000 (UTC) Date: Thu, 26 Sep 2019 00:14:44 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Andrew Morton cc: David Sterba , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pekka Enberg , David Rientjes , Ming Lei , Dave Chinner , Matthew Wilcox , "Darrick J . Wong" , Christoph Hellwig , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, James Bottomley , linux-btrfs@vger.kernel.org, Roman Gushchin , Johannes Weiner Subject: Re: [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two) In-Reply-To: <20190924165425.a79a2dafbaf37828a931df2b@linux-foundation.org> Message-ID: References: <20190826111627.7505-1-vbabka@suse.cz> <20190826111627.7505-3-vbabka@suse.cz> <20190923171710.GN2751@twin.jikos.cz> <20190924165425.a79a2dafbaf37828a931df2b@linux-foundation.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Tue, 24 Sep 2019, Andrew Morton wrote: > I agree it's a bit regrettable to do this but it does appear that the > change will make the kernel overall a better place given the reality of > kernel development. No it wont. - It will only work for special cases like the kmalloc array without extras like metadata at the end of objects. - It will be an inconsistency in the alignments provided by the allocator. - It will cause us in the future to constantly consider these exceptional alignments in the maintenance of the allocators. - These alignments are only needed in exceptional cases but with the patch we will provide the alignment by default even if the allocating subsystem does not need it. - We have mechanisms to detect alignment problems using debug kernels and debug options that have been available for years. These were not used for testing in these cases it seems before the patches hit mainline. Once in mainly someone ran a debug kernel and found the issue. > Given this, have you reviewed the patch for overall implementation > correctness? Yes, the patch is fine. > I'm wondering if we can avoid at least some of the patch's overhead if > slab debugging is disabled - the allocators are already returning > suitably aligned memory, so why add the new code in that case? As far as I know this patch is not needed given that we have had the standards for alignments for a long time now. Why would the allocators provide specially aligned memory just based on the size of an object? This is weird and unexpected behavior. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 604F7C4360D for ; Thu, 26 Sep 2019 00:14:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29DED21D7B for ; Thu, 26 Sep 2019 00:14:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29DED21D7B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B1B5C6B0006; Wed, 25 Sep 2019 20:14:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA4EA6B0008; Wed, 25 Sep 2019 20:14:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 944B06B000A; Wed, 25 Sep 2019 20:14:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 6BE776B0006 for ; Wed, 25 Sep 2019 20:14:45 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 094DE181AC9CC for ; Thu, 26 Sep 2019 00:14:45 +0000 (UTC) X-FDA: 75975150930.25.frame29_80c0c0f27751a X-HE-Tag: frame29_80c0c0f27751a X-Filterd-Recvd-Size: 3501 Received: from gentwo.org (gentwo.org [3.19.106.255]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 26 Sep 2019 00:14:44 +0000 (UTC) Received: by gentwo.org (Postfix, from userid 1002) id 17D1D3EEC6; Thu, 26 Sep 2019 00:14:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 150213E86C; Thu, 26 Sep 2019 00:14:44 +0000 (UTC) Date: Thu, 26 Sep 2019 00:14:44 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Andrew Morton cc: David Sterba , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pekka Enberg , David Rientjes , Ming Lei , Dave Chinner , Matthew Wilcox , "Darrick J . Wong" , Christoph Hellwig , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, James Bottomley , linux-btrfs@vger.kernel.org, Roman Gushchin , Johannes Weiner Subject: Re: [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two) In-Reply-To: <20190924165425.a79a2dafbaf37828a931df2b@linux-foundation.org> Message-ID: References: <20190826111627.7505-1-vbabka@suse.cz> <20190826111627.7505-3-vbabka@suse.cz> <20190923171710.GN2751@twin.jikos.cz> <20190924165425.a79a2dafbaf37828a931df2b@linux-foundation.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 24 Sep 2019, Andrew Morton wrote: > I agree it's a bit regrettable to do this but it does appear that the > change will make the kernel overall a better place given the reality of > kernel development. No it wont. - It will only work for special cases like the kmalloc array without extras like metadata at the end of objects. - It will be an inconsistency in the alignments provided by the allocator. - It will cause us in the future to constantly consider these exceptional alignments in the maintenance of the allocators. - These alignments are only needed in exceptional cases but with the patch we will provide the alignment by default even if the allocating subsystem does not need it. - We have mechanisms to detect alignment problems using debug kernels and debug options that have been available for years. These were not used for testing in these cases it seems before the patches hit mainline. Once in mainly someone ran a debug kernel and found the issue. > Given this, have you reviewed the patch for overall implementation > correctness? Yes, the patch is fine. > I'm wondering if we can avoid at least some of the patch's overhead if > slab debugging is disabled - the allocators are already returning > suitably aligned memory, so why add the new code in that case? As far as I know this patch is not needed given that we have had the standards for alignments for a long time now. Why would the allocators provide specially aligned memory just based on the size of an object? This is weird and unexpected behavior.