Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3630095yba; Tue, 9 Apr 2019 01:08:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqxsFbt4zMkdPTIvY11fNIh8VJLg5poV8MoF75u+FwXgEhT+gZt646LoPs5q7FiJn+Q0cxPO X-Received: by 2002:a63:5b4d:: with SMTP id l13mr31718132pgm.160.1554797319112; Tue, 09 Apr 2019 01:08:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554797319; cv=none; d=google.com; s=arc-20160816; b=dWkmE2/jEO+ZGteWZ/coySYOxNh2pyJqYTaMnfSVk8aaCXpdImHBRiJx0Lz9Q2MoQY idnrGLWI8Vlud4vQUabCR4qT5U6fJHDHqKEzIe4y+ePV3uJu7Ssqb6me+VkpsZS3EAPH V5H/RjSDSq8jHACX1ux5Ryf+PS+/XrHq5i/UVSY13u2inV198Fwqk31YchXp8XsjXeL8 tojIUldaFN0NFpXKM8/BRX/Q1DN0Uh1PT+r0/jz5O5XEz7dpZLNp7PHSKxQmDzbSXAbO k9Wdrd2erSaqVIDCpv+Hzf6kce7wwwgAwzt4zspu/sxe04Mq78+oFXUdceagKHZDmCvF 6IDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=lrz9BacXx7IE9OmicqnmhhfhbZYC7hsHUWLL+aOflZs=; b=ob/mKVKdVpGQTI/ji+RMidSwfsYgv2DSDGEE44InjCaMYBv8kfeYiBZcYXjKj6i594 b7pzdazSUnNN6cdYZzaVRQ29RzdLeF2qwVid9uZXQKzMdpkBCsFyH7fxLuJJK3vodSuF yIPsMulhcG6hrGsrsCyRVqcNozEosAjEPVJVuxNhdTcQ+BEzB3bYvAWIk4bDWn+Vyako IAGor+/+Xw0z3te5X8KT/WqqvnksgnO6LEKwvL2097oV5TFPJfOa6n5MNoq8tAXcS+FO m3lH4kmmFOOxeac56w39RgctRvDHyfDMDUOsquAIQvTbQtJQdqfrGUkqrp++VQeZznEd xQyQ== 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 g21si30003336pfg.286.2019.04.09.01.08.23; Tue, 09 Apr 2019 01:08:39 -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 S1726684AbfDIIHq (ORCPT + 99 others); Tue, 9 Apr 2019 04:07:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:44388 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726588AbfDIIHp (ORCPT ); Tue, 9 Apr 2019 04:07:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DAE55AC97; Tue, 9 Apr 2019 08:07:43 +0000 (UTC) Subject: Re: [RFC 0/2] guarantee natural alignment for kmalloc() To: Christoph Hellwig Cc: Christopher Lameter , linux-mm@kvack.org, Pekka Enberg , David Rientjes , Joonsoo Kim , Ming Lei , Dave Chinner , Matthew Wilcox , "Darrick J . Wong" , Michal Hocko , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, lsf-pc@lists.linux-foundation.org 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> <20190407080020.GA9949@lst.de> From: Vlastimil Babka Message-ID: Date: Tue, 9 Apr 2019 10:07:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190407080020.GA9949@lst.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/7/19 10:00 AM, Christoph Hellwig wrote: > 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. What about a LSF session/BoF to sort this out, then? Would need to have people from all three MM+FS+IO groups, I suppose.