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.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, 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 E187EC3A59B for ; Fri, 30 Aug 2019 17:41:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A734723426 for ; Fri, 30 Aug 2019 17:41:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazonses.com header.i=@amazonses.com header.b="jOwxuN0/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727930AbfH3Rlr (ORCPT ); Fri, 30 Aug 2019 13:41:47 -0400 Received: from a9-46.smtp-out.amazonses.com ([54.240.9.46]:43362 "EHLO a9-46.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727914AbfH3Rlr (ORCPT ); Fri, 30 Aug 2019 13:41:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567186906; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=O4l8bfyB+VvL+95TNWx4FpZqRMWRe8LWpmXp151rZPQ=; b=jOwxuN0/GsY64oKXgfJmdwBB+AXtX2WpGHqJuhQjx2ptbH8DVIIqkqyXxRD8yOn8 GV8ejswyFu4wYPPvC5trc2TJ+u/8YK8DHJOysSHUEOvy5EY/yEQJyv85OgQB3tVrNRO oEjKdNcHWMyjIds//broy3iaTxgNIeqHLNuDl3dY= Date: Fri, 30 Aug 2019 17:41:46 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Michal Hocko cc: Matthew Wilcox , Vlastimil Babka , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pekka Enberg , David Rientjes , Ming Lei , Dave Chinner , "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 Subject: Re: [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two) In-Reply-To: <20190829073921.GA21880@dhcp22.suse.cz> Message-ID: <0100016ce39e6bb9-ad20e033-f3f4-4e6d-85d6-87e7d07823ae-000000@email.amazonses.com> References: <20190826111627.7505-1-vbabka@suse.cz> <20190826111627.7505-3-vbabka@suse.cz> <0100016cd98bb2c1-a2af7539-706f-47ba-a68e-5f6a91f2f495-000000@email.amazonses.com> <20190828194607.GB6590@bombadil.infradead.org> <20190829073921.GA21880@dhcp22.suse.cz> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2019.08.30-54.240.9.46 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Thu, 29 Aug 2019, Michal Hocko wrote: > > There are many places in the kernel which assume alignment. They break > > when it's not supplied. I believe we have a better overall system if > > the MM developers provide stronger guarantees than the MM consumers have > > to work around only weak guarantees. > > I absolutely agree. A hypothetical benefit of a new implementation > doesn't outweigh the complexity the existing code has to jump over or > worse is not aware of and it is broken silently. My general experience > is that the later is more likely with a large variety of drivers we have > in the tree and odd things they do in general. The current behavior without special alignment for these caches has been in the wild for over a decade. And this is now coming up? There is one case now it seems with a broken hardware that has issues and we now move to an alignment requirement from the slabs with exceptions and this and that? If there is an exceptional alignment requirement then that needs to be communicated to the allocator. A special flag or create a special kmem_cache or something.