Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1821376yba; Sun, 7 Apr 2019 01:03:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDhgx+Wt3fvmqeEUlf+PNKvXu5DIIHODAhotVp17Pfxn5Jwu7jrCZ/ITsqprFu86hXiSop X-Received: by 2002:a62:209c:: with SMTP id m28mr22288572pfj.233.1554624195159; Sun, 07 Apr 2019 01:03:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554624195; cv=none; d=google.com; s=arc-20160816; b=J98zVARfeiFLsNDsEF/WK/+DhQqIbSdpFBm9s/liP5we5EDOmjVJrhHZ87hqopU4gc CeukoZ1KxHxaMMhGk4aUVxLGyaqgalY2U9qtudqdS8bTSjtzIQNl821WPlLEcmm0G9k5 gK83SJM9v/IHoQidrPSG6yaKv2c73r2zMPvC42HXXEgYmx/1TK8+10bQ/YamxJ6giKmD MwmnmNwPq2XiBWi3nMs/+JUDYk7JVT+rvevsrGFjIhOr0f5b2IcmhUUM4yz+4naOcPO6 CaTX43yTnsPgHgwc6lCQjp60rNGBlW301QYk3ZMVMVp/LaLmI444BuDWSMCjXlfRtxEM oqSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=csV0JTqzeAjwcMrmBTtPwMmBajuE/7/DOgkBiGrP9h0=; b=fhoT41gkzbFl944tRA9GHzpcl4eFA/bxR14Wihn+9exRNM7hHUlCeIAKqUfTkCzrbC IpdQqIK0iZcd7Wk1dBBSr17aTOh4tTQyanLzGr4LxKn1W+uNt662AVWynAFAr6LDp9jB AYa6Zh8dzXkbnBIFsJ38n4UKpkWBmewnuZ/HC3Tumqy0FdCez3i4myFhY0hyhojkL5Ac OdJU7Ji7YHVwonc9k1Df6RaZhdZDlVdUAZibKp27UNewqIMtdedgq39I0PLhqkkIdE6t P3CV8gnCwmmvXdmPMTpfmMUTk+xpIuYN3CCeJp6pK+XBdM3fwHBHiCRYHrhDJdVDBMOG lbIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r199si24796295pfc.271.2019.04.07.01.02.25; Sun, 07 Apr 2019 01:03:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726244AbfDGIAg (ORCPT + 99 others); Sun, 7 Apr 2019 04:00:36 -0400 Received: from verein.lst.de ([213.95.11.211]:35997 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725905AbfDGIAf (ORCPT ); Sun, 7 Apr 2019 04:00:35 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id D0B1E68B02; Sun, 7 Apr 2019 10:00:20 +0200 (CEST) Date: Sun, 7 Apr 2019 10:00:20 +0200 From: Christoph Hellwig To: Vlastimil Babka Cc: Christopher Lameter , linux-mm@kvack.org, Pekka Enberg , David Rientjes , Joonsoo Kim , Ming Lei , Dave Chinner , Matthew Wilcox , "Darrick J . Wong" , Christoph Hellwig , Michal Hocko , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org Subject: Re: [RFC 0/2] guarantee natural alignment for kmalloc() Message-ID: <20190407080020.GA9949@lst.de> References: <20190319211108.15495-1-vbabka@suse.cz> <01000169988d4e34-b4178f68-c390-472b-b62f-a57a4f459a76-000000@email.amazonses.com> <5d7fee9c-1a80-6ac9-ac1d-b1ce05ed27a8@suse.cz> <010001699c5563f8-36c6909f-ed43-4839-82da-b5f9f21594b8-000000@email.amazonses.com> <4d2a55dc-b29f-1309-0a8e-83b057e186e6@suse.cz> <01000169a68852ed-d621a35c-af0c-4759-a8a3-e97e7dfc17a5-000000@email.amazonses.com> <2b129aec-f9a5-7ab8-ca4a-0a325621d111@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b129aec-f9a5-7ab8-ca4a-0a325621d111@suse.cz> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 05, 2019 at 07:11:17PM +0200, Vlastimil Babka wrote: > On 3/22/19 6:52 PM, Christopher Lameter wrote: > > On Thu, 21 Mar 2019, Vlastimil Babka wrote: > > > >> That however doesn't work well for the xfs/IO case where block sizes are > >> not known in advance: > >> > >> https://lore.kernel.org/linux-fsdevel/20190225040904.5557-1-ming.lei@redhat.com/T/#ec3a292c358d05a6b29cc4a9ce3ae6b2faf31a23f > > > > I thought we agreed to use custom slab caches for that? > > Hm maybe I missed something but my impression was that xfs/IO folks would have > to create lots of them for various sizes not known in advance, and that it > wasn't practical and would welcome if kmalloc just guaranteed the alignment. > But so far they haven't chimed in here in this thread, so I guess I'm wrong. Yes, in XFS we might have quite a few. Never mind all the other block level consumers that might have similar reasonable expectations but haven't triggered the problematic drivers yet.